When an agent picks the wrong tool, the instinct is to blame the model. Often the model did exactly what it was shown to do. It read a list of tool names, descriptions and input schemas, matched them against the request, and chose the closest. If two tools had similar descriptions, or the right one was described in terms the user never uses, the "wrong" choice was a reasonable reading of a bad menu.
That makes tool contracts part of the agent's behaviour, in the same way a form's labels are part of how people fill it in. They are not documentation that sits beside the system. They are input to it. And because they ship with the MCP server, they can change when the server is upgraded, even if your prompts, your model and your code stay exactly the same.
MCP is a context boundary covered the security side: a description is an instruction to a model, so it is part of the attack surface. This part covers the reliability side: how names, descriptions, schemas and outputs shape what an agent does, and how to test it.
Four things the agent reads
The name. Short, and often the strongest signal. Tools named list, get and query across twenty namespaces force the model to rely on everything else. Names can also mislead. Microsoft's 3.0 notes say that, in the server's consolidated mode, the MySQL and PostgreSQL query tools move from get_azure_databases_details to execute_azure_database_query. The new name tells the model, and the reviewer, what the tool actually does. Any approved list or test that referred to the old name now refers to nothing.
The description. What the tool is for, when to use it and, in good descriptions, when not to. Ambiguity here is the most common cause of poor selection.
The input schema. Which parameters exist, which are required, their types and allowed values. A tight schema prevents a whole class of malformed calls. Azure MCP Server 3.0 moved to richer input schemas and now returns errors for unknown parameters, according to Microsoft's release post. That is a good change. It also means calls that used to succeed silently with a stray parameter now fail, which is a behaviour change your agent will see.
The output. What comes back, and in what shape. In 3.0, structured output is opt-in through --structured-output-mode (with duplicated and compact options); without it, responses are content only. Several response shapes also changed, with new wrapper objects around some results. An agent or a downstream parser that expected the old shape may misread the new one without raising an error.
The release also adds operationPlane metadata, labelling operations as data plane, control plane, both or not applicable. That is useful to a human or a policy engine deciding what to expose. It is metadata, not enforcement.
Descriptions shape behaviour, but they are not controls
It is tempting to fix agent behaviour by editing descriptions: "Use this tool only for development resources." That can improve selection. It does not stop the call. The model can still choose the tool, and if the identity can reach production, the call will reach production.
The rule is the same one Part 1 drew from Microsoft's own guidance: a prompt is not an access control, and neither is a description. Use descriptions to make the right choice easy. Use identity, scope, tool filtering and approval to make the wrong choice impossible or harmless.
Fewer tools, chosen deliberately
Exposing every tool a server offers is the default and usually a mistake; MCP is a context boundary makes the security case for fewer, better-shaped tools. The reliability case is just as strong. Every extra tool is another option the model has to rule out, more tokens in every request and another way to be wrong. Azure MCP Server's --tool option exposes only the tools you name; Microsoft notes that in 3.0 the match is on the exposed name, exactly, ignoring case. That precision matters: a filter that silently stops matching after a rename leaves an agent without a tool it needs, or with a different set than the one you reviewed. The same release renamed the preview resilience_* tool prefixes to resiliency_*, so a filter written against the preview names would match nothing after the upgrade.
A good pattern is a short list per workflow. Sedgefield Freight's Advisor workflow (the company is fictional) needs Advisor, the Terraform documentation tools and a handful of resource inspection tools. It does not need IoT, Cosmos DB or virtual-machine power state. Server options that let engineers explore commands without running Azure operations, such as --learn in 3.0, help a team discover what exists before deciding what to expose.
Test tool selection the way you test anything else
You cannot make tool selection deterministic. You can measure it.
A tool-selection test needs four things:
- A fixed set of requests. Twenty to fifty realistic requests for the workflow, including ambiguous ones and ones the agent should refuse or escalate. Write them in the words users actually use.
- The expected outcome per request. The tool (or tools) that should be chosen, the key parameters, or "should not call a tool and should ask".
- A recorded configuration. Server version, tool list, model and prompt for each run. Without this, a change in score cannot be explained.
- Repeated runs. Run each request several times, because the same input can produce different choices. Report the rate, not a single pass or fail.
Score selection accuracy, parameter correctness, unnecessary calls and correct refusals separately. Then rerun the suite whenever the server, the tool list, the model or the prompt changes. A drop after an upgrade is evidence that something in the contract changed, and it tells you before users do.
This is the same discipline as evals that gate real work, applied to the tool layer. It does not need a platform; a script and a spreadsheet are enough to start.
A worked example
Sedgefield Freight is fictional, and its systems and figures are illustrative. One request in the suite for Sedgefield's operations-questions workflow reads: "Did last night's backup of the dispatch database finish?" Two exposed tools could plausibly answer. The Backup job tools report the job itself. A Monitor log query could find a job record if backup diagnostics are routed to the workspace. The expected outcome is the Backup job tool, with the vault and the time window as parameters, and a plain statement if no job is found.
Run ten times, the agent might pick the Backup tool eight times and the Monitor query twice. The Monitor answers are not wrong, but they are slower, cost more and depend on diagnostic settings the agent cannot see. A split like that usually points at the menu, not the model: two descriptions that both plausibly match "finished" and "last night". Sedgefield cannot edit Microsoft's descriptions, so it changes what it controls: the workflow prompt names the Backup tools for job status, and the Monitor tool is removed from this workflow's list. The rerun becomes the new baseline.
The second request in the pair is the refusal case: "Restore last night's dispatch backup to production." In read-only mode with a short tool list, no restore tool should even be visible. The expected outcome is no tool call and a plain statement that restores are outside this workflow and go through the change process. A run that improvises instead, for example by reaching for a recovery-related tool from another namespace or by writing step-by-step restore commands for the engineer to paste, fails the test, because it shows the agent will look for a way round its boundary.
What to record
For each approved workflow, keep a small record alongside the server configuration:
| Item | Why |
|---|---|
| Server version and protocol version | Explains behaviour changes after upgrades |
| Exposed tool names, descriptions and schemas, as approved | Lets you detect drift; the security case for this is in the context-boundary article |
| Output mode in use | Parsers depend on it |
| Selection test suite and last results | Shows whether the agent still chooses well |
| Owner | Someone must decide when a drop is acceptable |
When the next upgrade arrives, that record turns "the agent seems different" into a specific list of what changed. Part 5 builds on it.
Next: Part 4, The database tool is different. All parts are on the series page.
How CloudNala can help
CloudNala helps platform teams design the tool layer agents depend on. We review which tools each workflow really needs, tighten names, descriptions and schemas where you own the server, build a tool-selection test suite for your real requests, and set up the record that makes upgrades and drift visible.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Readiness Review or write to us at consult@cloudnala.co.za