The agent may never discover the capability, because the server’s function is not enough on its own. The model relies on names, descriptions, schemas, and examples to infer usefulness. A powerful tool with poor metadata can look invisible. In practice, teams should assume the model can only use what the tool definition makes legible.
Why weak MCP metadata makes a capable tool effectively invisible
An mcp server is only as discoverable as the metadata the model can read. Strong runtime capability is not enough if the tool name, description, schema, and examples do not make the purpose legible. The practical failure is not execution, but discovery: the agent may never select the tool, even when it would have been the right one.
This is why server authors should treat the tool definition as part of the control surface, not as documentation after the fact. The model is inferring utility from the interface it sees, so vague or generic descriptions can suppress a genuinely powerful capability. For MCP-specific implementation detail, the MCP Security Guide covers the authorisation and metadata patterns that make server capabilities legible to agents.
What the model actually uses to decide whether a tool is worth invoking
Tool selection is usually driven by semantic cues, not just by raw capability. Names should indicate the action, descriptions should explain the outcome, schemas should expose the required inputs clearly, and examples should show the intended use. When those signals are weak, the tool can look like noise in a crowded toolset, especially if similar tools are better described.
That matters most when the server offers specialised actions that are not obvious from the surrounding application. A tool that can perform a sensitive or high-value function still needs a precise contract so the model can distinguish it from adjacent, less relevant tools. The broader agentic risk is captured well in OWASP Agentic AI Top 10, especially where tool misuse and identity or privilege abuse depend on how clearly the agent understands available actions.
In practice, the weakest point is often the description layer, not the transport or the backend function. If the metadata does not tell the agent when to use the tool, what success looks like, and what inputs are expected, the model may prefer a more generic but better-described option.
How to make a strong capability legible enough for an agent to use
The fix is to write tool metadata for selection, not just for human readability. Use names that encode the verb and object, descriptions that state the exact job the tool performs, and schemas that remove ambiguity about required fields and output shape. If a tool has meaningful preconditions, examples should make those conditions explicit so the model can map the tool to a concrete task instead of a vague capability.
Teams should also align the tool’s description with its trust model. If the tool depends on authorisation, token scope, or resource metadata discovery, that relationship should be obvious in the definition so the model can reason about when the tool is appropriate. The Model Context Protocol: Authorization specification is useful here because it shows how server capability, audience-bound tokens, and discovery interact in practice.
For practitioners, the test is simple: if an informed human would struggle to infer the tool’s purpose from the definition alone, the model will struggle too. Good metadata is not cosmetic, it is the entry ticket for use.
Risk and Threat Considerations
Weak semantic descriptions create a control failure as well as a usability failure. They can hide a valuable capability from the agent, but they can also make it harder to notice when a tool is too broad, too sensitive, or too easy to misuse because the description does not clearly state what it can do.
Failure mechanism: The agent cannot reliably match user intent to an available tool, so a useful capability goes unused or a less appropriate tool is chosen instead. In more dangerous cases, ambiguous metadata reduces scrutiny around privilege, making it easier for a powerful tool to be overlooked during review.
Impact: Missed automation, lower answer quality, and weaker security review of the server’s real authority. At scale, poor descriptions also increase the chance that teams ship tools whose power is obvious to developers but effectively hidden from agent selection logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Weak tool metadata affects whether agents select and use tools correctly. |
| ASI03 — Identity & Privilege Abuse | Poorly described powerful tools can obscure their authority and review boundaries. | |
| Recommendation — Describe tools so agents can select them only for the intended task and scope. Define tool authority clearly and restrict the action scope the agent can invoke. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | MCP tools are consumed programmatically, so vague contracts create unsafe use and selection errors. |
| Recommendation — Publish precise API contracts so clients can invoke endpoints safely and correctly. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers expose machine-consumed capabilities whose identity and trust need clear handling. |
| AC-6 — Least Privilege | Powerful tools should be constrained so hidden or misunderstood capability cannot expand access. | |
| Recommendation — Authenticate service-to-service interactions before exposing sensitive tool capabilities. Limit tool permissions to the minimum authority needed for the intended function. | ||
Practitioner Guidance
What to verify: Check that each tool description names the task, the intended inputs, and the expected outcome in language a model can reliably parse. If two tools overlap, make their boundary conditions explicit so selection is deterministic rather than accidental.
What good looks like: The best tool definitions let an agent distinguish capability, scope, and preconditions without guessing. If the description can be copied into a prompt and still not clearly indicate when to use the tool, it is too weak for dependable agent discovery.
Common mistake: Treating the backend function as self-explanatory. A capable server with vague metadata often loses to a less powerful tool that is easier for the model to understand.
Practitioner takeaway: For MCP, discoverability is part of security and operational reliability, because a tool that the model cannot interpret is effectively unavailable no matter how strong the underlying capability is.
Related resources from NHI Mgmt Group
- What happens when LiteLLM exposes MCP routes without verifying the target server’s auth mode?
- What happens when a malicious MCP server is allowed alongside legitimate enterprise tools?
- What happens when an MCP server is deployed without strong validation and monitoring?
- What happens when issue-mutation tools are left enabled on a Crashlytics MCP server without approval controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
