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.
When an MCP tool description becomes a control plane, not documentation
MCP tool descriptions are not inert comments. In practice, they are part of the agent’s instruction surface, because the model can read them while deciding whether to call a tool, how to frame the task, and what assumptions to carry forward. That is why treating descriptions as harmless prose creates a blind spot: you are reviewing code quality, but the model is also reading operational guidance.
The core failure is that teams assume the only security question is whether the tool implementation is safe. For MCP, the safer question is whether the description can alter model behaviour in ways the code scanner will never see. That distinction matters any time the tool is exposed to untrusted authorship, repository content, vendor-provided metadata, or copied examples that can steer the agent’s choice of actions.
In agentic environments, the description sits alongside runtime context, tool schemas, and output text as part of the decision path. A clean package does not guarantee safe use if the metadata nudges the model toward broader access, more permissive interpretation, or an unsafe sequence of calls. The MCP Security Guide is useful here because it treats MCP as an authorization and trust-boundary problem, not just an integration format.
Why code scanning misses the real risk
Static review can tell you whether the tool binary, package, or container is malicious. It cannot tell you whether the description text is persuasive, misleading, or strategically framed to influence the model. That creates a second instruction channel: the tool may be safe code but unsafe guidance, which means the attack surface exists even when the artifact passes conventional software checks.
This is especially important for tools that sit behind rich metadata, examples, or vendor-maintained descriptions. If those fields are copied into agent context, they can act like a policy override without ever changing executable logic. In the same family of failures, the Sentry MCP Agentjacking 2026 case shows how tool output and surrounding text can steer coding agents into unsafe behaviour even when the underlying trust in the source looks normal.
This is also why review needs to cover metadata, output text, and the model’s runtime decision path together. If you only inspect code, you miss instruction injection through text; if you only inspect text, you miss whether the model is actually capable of obeying it in context. The relevant control question is not “Is the package clean?” but “Can any text that reaches the model change the action it takes?”
A practical way to think about it is that MCP descriptions can change the effective authority of the tool. A description that overstates scope, implies trust, or frames the tool as recommended for a sensitive action can shape the model’s selection logic before a human ever sees the request.
What practitioners should verify before trusting an MCP tool
Practitioners should verify the whole tool envelope, not just the implementation. That means checking whether descriptions, examples, default prompts, and returned text are controlled, reviewed, and bounded in the same way as executable code. For MCP, this is a trust and authorization review as much as a software review.
The strongest operational test is whether an untrusted party could change tool behaviour by editing text alone. If that is possible, the tool is not safely governed, because model-visible metadata has become a manipulation surface. The Model Context Protocol: Authorization specification is the right external reference for the boundary between tool exposure and authenticated, audience-bound use.
When the question is broader than one tool, review should extend to tool registration and discovery. If the agent can ingest a catalog entry, README text, or generated description and treat it as guidance, then the review process must validate that text with the same seriousness as the endpoint itself. That is why guidance about agent tooling in the agentic AI applications guide remains relevant even when the immediate issue looks like a documentation problem.
Practitioner Guidance: Treat every model-visible tool field as security-relevant, then decide whether it can influence tool choice, scope, or sequence. If the answer is yes, put it in review scope, not just the package scanner.
What to verify: Confirm which fields are consumed by the agent runtime, which are editable by tool authors, and which are exposed to downstream models or assistants. A description that can alter behavior should be approved, versioned, and monitored like policy text.
Common mistake: Teams often gate only on malicious code and ignore manipulative prose, examples, or outputs. That leaves a clean artifact that still functions as an instruction channel.
Practitioner takeaway: The security boundary is the model’s interpretation path, not the code archive alone. If text can change the action, it belongs in control review.
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 | MCP descriptions can steer tools and shape unsafe tool selection. |
| ASI03 — Identity & Privilege Abuse | Description-driven tool use can expand effective authority in agent workflows. | |
| Recommendation — Review tool-visible text to prevent agents from misusing tools. Constrain agent actions so metadata cannot broaden privilege. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | MCP tool text can cause unsafe downstream API calls and use patterns. |
| API8 — Security Misconfiguration | Exposed or editable metadata can create a misconfigured trust boundary. | |
| Recommendation — Validate how the agent consumes tool guidance before allowing calls. Harden tool metadata and defaults to reduce unsafe exposure. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | If descriptions steer actions, privilege must be bounded at runtime. |
| Recommendation — Limit tool and agent permissions to the minimum required. | ||