MCP Describe Injection: Audit Tool Descriptions Like Code

Ben Bar lev — Wed, 26 Aug 2026 19:22:11 +0000

MCP Describe Injection: Audit Tool Descriptions Like Code

A practical guide to a real, under-covered MCP attack surface — and a dependency-audit mindset you can apply today. No vendor required for the checklist at the end.

A single install line stamps every tool in an MCP server onto the prompt your model reasons over, and nobody reviews the description. One install becomes a full tool slate — and you never looked at the contents.

The Model Context Protocol is the layer letting agents call tools and read resources across files, databases, email, and internal APIs. That's powerful. It also means a server's metadata — the tool descriptions the model reads at the top of every session — is now part of your attack surface. This post is about one specific, demonstrated attack on that surface: tool poisoning, and how to reduce it with the discipline you already use for dependencies.

1. What tool poisoning is — and why it isn't just indirect prompt injection

Tool poisoning hides malicious instructions in a tool's metadata at registration time, before anything executes. When the agent picks the tool later, it treats those metadata strings as trusted context. Nothing has run yet, so the attack hasn't "output" anything to scan.

This is related to indirect prompt injection (IPI), but it sits earlier in the pipeline. An IPI payload typically arrives in a tool's runtime output. A poison payload arrives with the tool itself, in the schema the model reads. There is no runtime event to catch. MCPTox, the benchmark, formalizes this exactly.

2. The numbers you can cite

The MCPTox benchmark (arXiv:2508.14925) measured agent robustness to tool poisoning on real servers:

45 live MCP servers, 353 authentic tools, three attack templates delivered as tool-description payloads.
20 prominent LLM agents evaluated.
Highest attack success rate: o1-mini at 72.8% (Phi-4 70.2%, GPT-4o-mini 61.8%). Average ASR across all models was 36.5%.
The highest refusal rate across all models was Claude-3.7-Sonnet, under 3%. Agents rarely refuse a poisoned call, even the ones most inclined to.

The reason: a poisoned action is only visible as malicious if you detect it. But it executes through an already-trusted tool for a seemingly-legitimate operation, so content-based safety alignment gets nothing suspicious.

3. Why the model can't just read around it

OWASP LLM01 states the core issue: an LLM makes no architectural distinction between instructions and data — both live on the same token stream. You cannot rely on a model to separate "this is a system instruction" from "this is tool metadata describing what the tool does."

In MCPTox, adding classic tag-based hijacking markers (like <IMPORTANT> or "ignore previous instructions") raised attack success by only ~2-3%. Placement, not formatting, decides the outcome.

4. Why safety alignment fails

A security-conscious model refuses when it decides a request is malicious. With tool poisoning, nothing looks malicious. The agent is asked to "send an email to this address" through a tool it already trusts, so no content filter fires and no alignment correction engages.

This is the key MCPTox finding: refusal rates were near zero (Claude-3.7 under 3%), and the dominant failure mode was the model directly executing the poisoned call.

5. The protocol already names the boundary

The MCP specification (2025-11-25) addresses this directly:

"Clients MUST consider tool descriptions to be untrusted unless they come from trusted servers."

It also keeps a human in the loop: "there SHOULD always be a human in the loop with the ability to deny tool invocations." Clients own the enforcement. The boundary is defined; how clients enforce it is the interesting part.

6. What to do today (no vendor required)

Treat every MCP description as code, not prose. Read the schema like you'd review a diff before approving a dependency bump.
Pin server versions. A mutable registry is the same risk as a mutable dependency.
Scope to least privilege. Use an allowlist that starts empty.
Gate state-changing tools. Anything that writes, sends, deletes, or spends should be allowed explicitly.
Add a parameter gate or human approval on high-impact calls. When a tool has side effects, a human should confirm the specific call.
Keep an evidence trail. Record what was called, with what arguments, and what was allowed.

The last point is where a control + evidence layer fits — an opt-in checkpoint that gates calls and records decisions as recomputable evidence. Not a sandbox, and no claim to intercept everything.

Close

Models keep getting more capable, and the trust boundary doesn't move. The tool set in your agent's MCP tier is now part of your supply chain. Next time you hit "install server," ask: is the description a dependency you've actually reviewed?

Sources: MCPTox (arXiv:2508.14925); MCP Specification 2025-11-25; OWASP LLM01 (2025). Figures as reported by the cited primary sources.

DEV Community: Ben Bar lev

MCP Describe Injection: Audit Tool Descriptions Like Code

MCP Describe Injection: Audit Tool Descriptions Like Code

1. What tool poisoning is — and why it isn't just indirect prompt injection

2. The numbers you can cite

3. Why the model can't just read around it

4. Why safety alignment fails

5. The protocol already names the boundary

6. What to do today (no vendor required)

Close