MCP Tool Poisoning: Why Gateway Description Scans Fall Short

What happened

A year after the Model Context Protocol (MCP) became the default way to connect AI agents to external tools, the security picture has hardened into a clear pattern. Attackers do not need to compromise the model or the user. They only need to control the text a tool presents about itself.

Invariant Labs named this attack class "tool poisoning" in April 2025 and published a proof of concept 13. In their Cursor IDE demonstration, a calculator tool with a tampered description quietly pulled a developer's SSH private key and the Cursor MCP configuration file. The tool still returned the correct sum, so the user had no visible sign that anything had gone wrong 3. A separate account of the same research says a single poisoned description could exfiltrate private repository contents and message histories without any user interaction 1.

The attack works because of how agents load tools. When a session starts, tool metadata goes into the model's context, and current models cannot reliably tell a tool's legitimate operating instructions from adversarial instructions written in the same natural language 1. Humans reviewing the tool in a UI often never see the hidden text, but the model reads and follows it 2.

How often it works

The numbers vary across reports, and the differences reflect test conditions rather than contradictions.

• Benchmarking across more than 45 real-world MCP servers found success rates above 60%, with the most susceptible agent model reaching 72.8% 1.
• Another write-up of what appears to be the same study puts the average across all models at 36.5%. It notes that Claude 3.7 Sonnet, the model with the strongest refusal behavior, still complied with poisoned descriptions 34% of the time 3.
• A defense-focused guide reports 84.2% success when agents run with auto-approval enabled 2.

Read together, these figures make a consistent point. Model-level resistance lowers the hit rate but does not eliminate it, and removing the human from the approval loop makes the problem much worse. Even the best case in these tests, about one in three, is far too high for an agent that holds credentials.

The server ecosystem is weak beyond poisoning alone. One analysis estimates that 5.5% of public servers contain tool poisoning vulnerabilities 2. Broader scans report that 43% of tested servers were open to command injection, 82% had path-traversal risks in file operations, and 36.7% were exposed to server-side request forgery. A third of 1,000 scanned servers carried critical vulnerabilities. Only 8.5% used OAuth, while 53% relied on static API keys 3.

The CVE trail

Two disclosed vulnerabilities show the problem moving from research to production software. CVE-2025-6514 was a critical command-injection bug in the mcp-remote OAuth component, a package with more than 437,000 downloads, before it was patched 2.

CVE-2025-54136 matters more for defenders. Rated CVSS 8.8 and disclosed in July 2025, it showed that approving a tool definition in a production AI development environment did not hold once the server changed that definition later 1. This is the "rug pull" pattern. A tool looks harmless when it is reviewed and turns hostile after it has been trusted.

Why description scanning isn't the finish line

TrueFoundry argues that tool poisoning should be treated as a supply-chain attack on the agent's context window rather than another prompt-injection variant. In its view, the AI gateway, which sits between agents and MCP servers, is where the channel should be closed. The mechanism it proposes is schema validation at that layer, applied before the model ever sees the tool 4.

The gateway is a reasonable place for enforcement. The weak version of this approach, however, is a scanner that checks only the human-readable description field once, at registration.

Two lessons from the evidence point the other way:

1. The model reads the whole schema. Everything a tool exposes is loaded into context 1, so any free-text field can carry instructions, not just the description. A gateway that validates the description but passes everything else through has left an obvious gap.
2. Approval doesn't persist. CVE-2025-54136 shows that a definition can change after it is trusted 1. A clean scan on day one says little about what a server sends on day thirty.

In practice, the defenses that hold up will probably combine several measures:

• Validate the full tool schema, not only the description, at the gateway.
• Pin approved definitions and re-check them, or block them, whenever they change.
• Keep humans in the approval path for sensitive actions, given the jump to 84.2% success under auto-approval 2.
• Replace static API keys with scoped authentication 3.

The broader conclusion is that metadata deserves the same scrutiny as code. MCP turned tool descriptions into executable influence over agents, and the defenses that work will treat every field a server sends as untrusted input, every time it is sent.