MCP tool descriptions shape model selection more than schemas do

At a glance

What this is: Archestra says MCP tool descriptions function as the model’s primary selection signal, and weak wording can make a well-built tool effectively invisible.

Why it matters: For IAM and NHI teams, that matters because tool selection is part of the control plane for agent behavior, and vague descriptions can undermine governance even when authentication and routing are sound.

Context

MCP tool descriptions are not static documentation. They are runtime instructions that help an agent decide whether to call a tool, ignore it, or choose a different one, which makes the wording part of the operational security surface rather than a cosmetic detail.

That matters because the model sees the tool name, description and schema metadata as the full pitch. In practice, a hedged description can weaken tool selection just as much as a missing entitlement can weaken access governance, especially when the same agent is choosing among multiple similar tools.

Key questions

Q: What breaks when MCP tool descriptions are treated as harmless documentation?

A: Security teams miss a second instruction channel that can steer the model even when the package is clean. The tool may be safe code but unsafe guidance, which means code scanning alone cannot tell you whether the agent will be manipulated. Review has to include metadata, output text, and the model’s runtime decision path.

Q: Why do hedged MCP descriptions reduce reliable tool use?

A: Hedged wording lowers the model’s confidence about when a tool is appropriate, especially when another tool has a sharper trigger phrase or a more direct description. The result is not just bad copy. It is poorer control over agent behaviour. If the description does not tell the model when to call the tool and when to avoid it, the model will improvise.

Q: How should teams write MCP descriptions for overlapping tools?

A: Describe the specific job, the user signal that should trigger the call, the cases where the tool should not be used, and the shape of the output. That structure gives the model a decision boundary instead of a generic capability statement. Overlapping tools need explicit separation, or the model will infer the wrong one from context.

Q: Should identity teams treat MCP tool descriptions as part of access governance?

A: Yes. In agentic environments, the description is part of how access is exercised because it influences whether the model routes to a capability at all. If the text is ambiguous, the governance intent behind the tool can be diluted before any authentication or authorization decision is enforced. Treat the wording as a control surface, not a note field.

Technical breakdown

Why MCP tool descriptions behave like prompt instructions

At tool-selection time, the model is not reading a product manual. It is reading a compact instruction set made up of the tool name, description and parameter metadata, then using that text to decide whether the tool is relevant enough to call. That means the description is closer to a control signal than a documentation field. If the copy is vague, overly generic or full of hedges, the model has less confidence about when to use it and may route elsewhere even when the tool is technically correct. In effect, the description becomes part of the selection policy. See the MCP Security Guide.

Practical implication: Treat every tool description as an input to model routing, not as descriptive prose.

How hedging, trigger signals and failure cases change tool choice

The article highlights three things the model needs. First, a concrete verb-led statement of what the tool does. Second, an explicit trigger that matches how a user will ask for it. Third, a clear negative case that tells the model when not to use it. That combination reduces ambiguity and helps the model distinguish between overlapping tools. The key mechanism is not persuasion by style alone. It is disambiguation. When the description names the common use case and the exclusion boundary, the model has enough structure to select the right tool without guessing. See the AI Agent Tool and Plugin Security Guide.

Practical implication: Rewrite descriptions to include trigger phrases and disqualifiers, not just capability summaries.

Why schema text alone is not enough for MCP governance

MCP servers expose more than a single description field. The input schema and parameter descriptions also influence how the model plans a call, but they do not compensate for a weak core description. If the top-level text fails to explain the job, the model can still overlook the tool before it ever evaluates parameter detail. That makes description quality a governance issue for agentic systems: the operator may believe a tool is available and well-structured, while the model experiences it as uncertain or low-confidence. In practical terms, naming and description hygiene are part of the access path for AI agents. See the NHI Authentication Guide.

Practical implication: Audit tool metadata as a control surface, not a documentation exercise.

Threat narrative

Attacker objective: The objective is to influence agent tool selection so the model uses the wrong workflow or ignores the intended one, degrading control and reliability.

1. Entry occurs when an AI agent receives a tool list and evaluates the descriptions as part of its runtime decision-making. A vague or hedged description reduces the chance that the correct tool is selected.
2. Escalation happens when the agent chooses a nearby but less appropriate tool because the wording failed to distinguish the true trigger, the false trigger and the expected output.
3. Impact is a governance failure rather than a classic intrusion: the environment remains intact, but the agent’s behaviour shifts away from intended control boundaries and toward incorrect or lower-value actions.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool descriptions are now a governance control, not a documentation convenience. The article shows that the model reads descriptions at the moment of action, so wording quality directly affects whether a tool is selected at all. That makes the description field part of the operational identity of the tool, especially where agents mediate access to data or workflow functions. Practitioners should treat this as a control design problem, not a copy-editing problem.

The real failure mode is selection ambiguity, not syntax failure. The schema can be valid and the backend can work perfectly, yet the agent still skips the tool because the description does not tell it when to prefer one path over another. That is a reminder that in agentic systems, governable behaviour depends on the quality of the semantic boundary around each capability. MCP security guidance becomes relevant here because the implementation details only matter if the model can reliably pick the right surface.

Named concept: description-driven tool governance. This is the idea that tool descriptions, triggers and exclusion phrases function as a lightweight policy layer for agent action selection. The concept matters because many teams focus on authentication and gateway controls while leaving the agent with weak routing signals inside the trusted zone. The practical conclusion is simple: if the description is vague, governance is already weakened before the first tool call.

MCP teams should not assume that better infrastructure compensates for weaker prompt-level control. The article’s central point is that a model can receive the same tool list and still behave differently based on wording alone. That puts pressure on operating models that treat tool registration as sufficient. For identity and access teams, the lesson is to align tool naming, description quality and permissions as one control plane, not three disconnected tasks.

Agentic security starts at selection time, not just at execution time. Once a model has chosen the wrong tool, downstream policy often arrives too late to restore intent. That is why prompt-fragment quality belongs in the same governance conversation as least privilege, scoped access and monitored execution. The practitioner takeaway is to manage tool descriptions as enforceable micro-policy, not as optional metadata.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Description-driven tool governance: MCP teams should think of tool copy as policy-in-text. If the model cannot infer when to call a tool, when to avoid it and what it returns, then selection becomes guesswork and governance becomes brittle. That is especially true when the same agent is exposed to multiple tools that differ only by nuance, not by function.

The practical signal for security and IAM leaders is that metadata quality now sits alongside permissions and network controls in the agent control stack. A tool that is technically available but poorly described is operationally under-governed, because the model may never reach the execution step where other controls can help.

For practitioners

• Audit every MCP tool description for selection clarity Replace hedged copy with a verb-led statement, a concrete trigger, a clear do-not-use condition and a short return shape.
• Add negative cases to overlapping tools Where two tools can plausibly satisfy the same request, specify the boundary between them so the model knows which one to choose first.
• Review schema property descriptions as routing signals Make parameter descriptions explicit enough that the model can infer required inputs without treating the field as a generic hint.
• Test tool selection with realistic user phrasing Run fresh prompts that mirror how people actually ask for help, then rewrite the descriptions until the correct tool is chosen consistently.

Key takeaways

• Weak MCP descriptions can suppress correct tool selection even when the schema and backend are sound.
• The issue is not cosmetic wording, but the model’s ability to distinguish trigger, exclusion and output shape.
• Teams should govern tool copy as part of the access path for agents, not as optional documentation.

Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Tool and Plugin Security Guide · NHI Authentication Guide · Smithery.ai MCP hosting breach 2025

Key terms

• MCP Tool Description: A MCP Tool Description is the structured definition of a tool that an AI agent can discover and call through the Model Context Protocol. It specifies the tool name, purpose, inputs, outputs, and constraints in machine-readable form, so the agent can invoke external capabilities safely and consistently during execution.
• Tool Selection Manipulation: An attack in which inputs are crafted to steer an agent toward the wrong tool, interface, or privilege level. The goal is to move a request from a constrained path into a more powerful one, creating unauthorized access to data, systems, or business actions.
• Parsing Ambiguity: Parsing ambiguity occurs when different components interpret the same input in different ways. In security controls, that can let a value pass one check while being understood differently later by the application, proxy, or library. Attackers often exploit these gaps to bypass allowlists or redirect traffic.
• Description-Driven Governance: A control pattern in which tool descriptions, triggers and exclusion rules are treated as policy inputs that shape agent behaviour. It is a lightweight form of governance that sits between inventory and execution, especially useful where multiple tools expose similar capabilities.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the wider security programme they operate every day.