What breaks when MCP tool descriptions can be modified by an attacker?

Why This Matters for Security Teams

When MCP tool descriptions can be altered, the problem is not just misleading documentation. It is a trust collapse inside the agent’s decision path. The model may still call an approved server, but if the metadata is attacker-controlled, the agent can be steered into unsafe actions while every outer control appears to pass. That is why current guidance increasingly treats tool metadata as security-sensitive, not cosmetic, as reflected in the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP NHI Top 10.

This matters because many teams still assume that allowlisting the MCP server, approving the connector, or checking the endpoint identity is enough. It is not. The attacker only needs a foothold in the metadata path to change tool semantics, mask exfiltration intent, or reframe a dangerous action as a routine task. In practice, many security teams encounter this only after a “trusted” tool has already been used in a way no reviewer expected.

How It Works in Practice

MCP changes the risk model because the agent does not merely execute code; it interprets tool descriptions, arguments, and suggested usage patterns at runtime. If an attacker can modify those descriptions, they can influence the model’s plan before any command is executed. That makes metadata integrity just as important as endpoint authenticity. The right control objective is to verify that the agent is consuming signed, immutable, or otherwise integrity-protected tool definitions, not just a live server response.

In practice, strong patterns include source pinning, signature verification for tool manifests, strict separation between developer-authored tool contracts and runtime content, and policy checks that compare intended action against allowed capability. Where feasible, teams should pair this with runtime authorization and constrained execution so the agent cannot treat description text as permission. This aligns with the direction of the CISA cyber threat advisories and NIST’s broader control discipline in NIST SP 800-53 Rev 5.

• Verify tool manifests before the agent reads them.
• Separate tool identity from tool description content.
• Use policy evaluation at request time, not only pre-approval.
• Log tool metadata changes as security events.
• Treat unexpected description drift as a tampering indicator.

NHIMG’s Analysis of Claude Code Security and its Ultimate Guide to NHIs both point to the same operational issue: once metadata is mutable, the agent’s trust boundary no longer matches the operator’s trust boundary. These controls tend to break down when MCP servers are dynamically generated, multi-tenant, or chained through proxy layers because the description source becomes difficult to authenticate end to end.

Common Variations and Edge Cases

Tighter metadata controls often increase operational friction, requiring organisations to balance deployment speed against integrity guarantees. That tradeoff is real, especially in fast-moving agentic environments where tool sets change daily. Current guidance suggests that immutable manifests and signed descriptions are preferable, but there is no universal standard for every MCP deployment yet, so implementation often depends on risk tolerance and tooling maturity.

Edge cases appear when descriptions are assembled from multiple sources, localized for users, or enriched by another service before reaching the agent. Those transformations can unintentionally create a tampering channel even without a direct attacker on the MCP host. The safest posture is to treat any post-signature rewrite as untrusted unless the pipeline itself is protected and auditable. NHIMG’s 52 NHI Breaches Analysis shows how often identity failures are caused by overlooked trust boundaries rather than obvious credential theft.

Where teams use agentic workflows with multiple tools, this problem can become a chain risk: one poisoned description can redirect the model toward a second, more privileged action. That is why OWASP’s Agentic AI Top 10 and the Anthropic AI-orchestrated cyber espionage report both reinforce the same lesson: approval alone is not control when runtime guidance can be manipulated.

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 agent frameworks trust tool names or default permissions too much?
• What breaks when MCP servers are approved once but allowed to change later?