What breaks when an MCP server’s tool descriptions do not match its actual actions?

Why This Matters for Security Teams

When an mcp server’s tool description says one thing and the runtime action does another, the control plane stops being trustworthy. Reviewers, agent developers, and security approvers may validate the stated purpose, yet the model will still invoke the function based on the declared surface area. That creates hidden privilege, weakens change control, and turns documentation drift into an authorization problem. In MCP environments, the description is not just metadata; it is part of the decision signal.

This is especially dangerous in agentic workflows because the agent can chain calls, reuse tokens, and execute follow-on actions without a human reading each step. The practical risk is not merely a misleading label, but an action that escapes the original risk assessment. Current guidance from OWASP Agentic AI Top 10 and NIST control thinking both point toward runtime verification, not blind trust in declared intent. NHIMG research on The State of MCP Server Security 2025 also shows how often MCP deployments expose more than teams expect, including hard-coded secrets and weak scoping. In practice, many security teams encounter this only after an agent has already used a “safe” tool to perform an unsafe action.

How It Works in Practice

The failure starts with a mismatch between the contract and the code. An MCP server may advertise a tool as “read-only,” “status check,” or “ticket lookup,” while the implementation can delete records, trigger workflow changes, or access broader data than the label implies. The AI system treats the description as a routing and planning cue, so the agent may select the tool for a benign goal and then inherit the full runtime effect. That is why static review alone is not sufficient.

Security teams should treat MCP tool metadata as an authorization input, not as proof. The practical pattern is:

• Validate tool descriptions against the real function, side effects, and data scope.
• Require least-privilege execution boundaries for each tool, not just for the server overall.
• Use runtime policy checks so the requested action is evaluated at call time, with context.
• Separate read, write, and administrative tools instead of bundling them behind one generic interface.
• Log both the declared purpose and the actual effect so reviewers can spot drift quickly.

This maps closely to the intent of NIST SP 800-53 Rev. 5 Security and Privacy Controls, which emphasizes access control, accountability, and system integrity, even though it does not prescribe MCP-specific mechanics. NHIMG’s Analysis of Claude Code Security is a useful reminder that agent tooling becomes risky when the model is allowed to infer trust from interface claims instead of verified behaviour. These controls tend to break down when a single MCP tool wraps multiple backend operations, because the description becomes too coarse to represent the real privilege boundary.

Common Variations and Edge Cases

Tighter tool verification often increases operational overhead, requiring organisations to balance safer authorisation against faster agent development. That tradeoff becomes visible in fast-moving environments where tool schemas change frequently and product teams want to ship before security review is complete. Best practice is evolving here, and there is no universal standard for how granular MCP descriptions must be, but the direction is clear: the description must not overstate safety or understate side effects.

Edge cases include tools that are technically read-only but reveal sensitive information, tools that trigger indirect effects through downstream systems, and tools whose behaviour changes with tenant context or feature flags. A “search” tool may still exfiltrate secrets if the backend index is over-permissive; a “create” tool may generate administrative impact if it triggers automation chains. That is why review should include implementation-level testing, not only schema inspection. Where possible, map tool classes to explicit policy and inspect them against the actual runtime paths. This is consistent with the risk themes in The State of MCP Server Security 2025 and the agentic guidance in OWASP Top 10 for Agentic Applications 2026, which both stress that declared behaviour is not a substitute for verified behaviour.

Related resources from NHI Mgmt Group

• What breaks when MCP tool descriptions can influence AI agents?
• What breaks when agents trust MCP tool descriptions by default?
• What breaks when MCP tool descriptions can be modified by an attacker?
• What are MCP Authorization Extensions and how do they help organizations?