MCP Tool Poisoning Attacks Explained

MCP tool poisoning is an attack that hides malicious instructions inside the metadata an AI agent trusts by default: the tool descriptions, names, and parameter schemas a server hands over the moment a connection opens. The agent reads that metadata as trusted configuration before a single character of user input ever arrives. Understanding how this works, and why the protocol offers no built-in check against it, is table stakes for anyone putting agents into production right now.

Model Context Protocol exists to standardize how an AI agent finds and calls outside tools like Slack, GitHub, a database engine, and a code sandbox. When a server publishes a tool called send_email, the agent takes its description at face value. That's the whole point of the protocol, and it's also the hole in it.

MCP gives clients no cryptographic proof that a tool description hasn't been tampered with. There's no way to check that the definition running today matches the one a security team reviewed at onboarding, and no runtime check for adversarial text hiding inside a description field. Every piece of text that reaches the model, the user's prompt, the system message a developer wrote, and the tool description a third-party server published, is in the same context window with equal weight. TrueFoundry said in 2026 that whoever writes into that window writes the model's instructions. Security researchers have made the same point: the protocol trusts whatever metadata a server operator decides to publish, full stop, with no mechanism for a client to push back on that trust.

By early 2026, MCP servers covered calendars, code execution, financial data, and enterprise messaging. That spread matters because it sets the blast radius once someone actually weaponizes the gap.

What tool poisoning is

Tool poisoning means malicious instructions get buried inside an MCP tool's name, description text, or parameter schema, and the agent processes that content as trusted setup information before a user has typed anything. Invariant Labs named the technique in April 2025 and published a proof-of-concept showing exfiltration of private repository contents and message histories with zero user interaction required.

Prompt injection and tool poisoning get lumped together, but they're different problems with different fixes. Prompt injection is an input-validation issue: the danger sits wherever a user-supplied string enters the prompt, and known defenses exist for that. Tool poisoning is a supply-chain issue. The agent depends on server-side metadata written by someone it never agreed to trust. That metadata looks like configuration, JSON Schema fields, structured data pulled at boot, so it slides right past the review process built to catch bad user input.

OWASP puts tool poisoning at the overlap of LLM01 (Prompt Injection) and LLM05 (Supply Chain Vulnerabilities), which TrueFoundry called the worst possible spot to land in 2026, because most security teams staff one of those concerns and not the other. The OWASP MCP Top 10 project filed it as MCP03:2025, and security researchers have identified tool description poisoning and malicious capability registries as distinct threat categories in their own right.

None of this is a bug in one model. It's a structural fact about how large language models work: they can't reliably tell an operational tool description apart from an adversarial instruction written in the same natural language, sitting in the same field. TrueFoundry's writeup shows that two CVEs, MCPoison (CVE-2025-54136) and CurXecute (CVE-2025-54135), made that concrete: both demonstrate that anyone who controls or compromises an MCP server can write commands straight into a tool descriptor with no sanitization and full ambient authority. Picture a description where the first sentence reads like a normal tool blurb and the second sentence quietly tells the model to do something else. The model has no concept of "my developer told me this" versus "a vendor's server told me this." It's all just text.

The three primary attack variants

All three variants trace back to the same root cause: MCP clients inherit trust from a server the moment they connect, and nothing forces them to re-check that trust later. An industry security body flagged this exact pattern in July 2026.

Tool Description Poisoning is the core form. The attacker writes adversarial instructions straight into a tool's description field or parameter schema, and the agent loads it at session start. A person scanning the interface sees nothing wrong, but the model reading the raw context sees the whole payload. Documented techniques show that attackers hide it using Unicode homoglyphs, zero-width space characters, or by tacking the malicious text onto the end of an otherwise normal-looking description. Invariant's own proof-of-concept is the clean example here: a fake "add numbers" tool ships a description telling the model to make the legitimate email tool BCC every outgoing message to an attacker's address, framed as a fix for "proxying issues." The malicious tool orders the trusted one around without ever being called itself. It just orders the trusted one around.

Rug-Pull Attacks happen after approval, not before it. An attacker registers a clean, boring tool, gets it reviewed and signed off, then quietly swaps in a poisoned schema later. MCP clients pull fresh tool lists on a set schedule or when they get a notifications/tools/list_changed message, and the model treats whatever comes back with the exact same authority as the original approved version. CVE-2025-54136, rated 8.8 on the CVSS scale and disclosed by NIST in July 2025, demonstrated this class of weakness in real AI development tools. Any audit run against the old schema becomes obsolete the moment a refresh pulls the new one; it was accurate once and useless a moment later. There's no version pinning, no content hash, nothing in the protocol that locks a tool description to the version somebody actually signed off on.

Tool Shadowing works by identity theft rather than redefinition. A malicious server registers a tool sharing a name, or a near-identical description, with a legitimate tool already sitting in the agent's context. Calls meant for the real tool get intercepted by the fake one, and the agent follows the poisoned version while believing it's still talking to the trusted one. This gets especially dangerous once an agent pulls tool catalogs from multiple servers into a single merged context, since there's no built-in check for name collisions across sources.

2025 research also documented related patterns, including schema poisoning, where the contract governing agent-to-tool calls gets altered so an innocent-sounding action maps to something destructive; and cross-server attacks built around OAuth confused-deputy weaknesses or what's been called the "lethal trifecta," combining access to external content, access to private data, and an outbound network connection in one agent session.

Why input filters and existing guardrails miss these attacks

The poison appears in server-side tool metadata, not in anything the user typed, so input classifiers and prompt guardrails end up watching the wrong door. Standard antivirus and endpoint security tools don't parse MCP tool metadata at all, because that's not what they were built to look at.

Caching makes it worse. Plenty of clients cache the results of tool discovery, so a poisoned schema fetched once keeps infecting every session afterward until someone manually clears that cache, which in practice almost never happens.

A study out of the New York Institute of Technology (arXiv:2603.21642) tested seven widely used MCP clients, Claude Desktop, Claude Code, Cursor, Cline, Continue, Gemini CLI, and Langflow, and found real gaps between them. Claude Desktop came out with strong guardrails in place. Cursor showed high susceptibility to cross-tool poisoning, hidden parameter exploitation, and tools getting invoked without authorization. The study checked for static validation, parameter visibility, injection detection, user warnings, sandboxed execution, and audit logging, and coverage varied a lot from client to client.

A separate project called MCPXKIT (arXiv:2508.12538, first posted August 2025 and revised in May 2026, from researchers at Tsinghua, Ant Group, and Swinburne) catalogued 31 distinct MCP attack methods sorted into four categories. Thirty-one is a big number, and it tells its own story: no single type of guardrail is going to close a surface that wide.

One design fact produces all of it: the model gives a tool description the same authority it gives a developer's system prompt. The model gives a tool description the same authority it gives a developer's system prompt. There's no wrapper marking that description as data rather than instruction, so whatever safety alignment a model has is aimed at the wrong layer of the problem.

MCPTox benchmark findings on attack success rates against real models

MCPTox (arXiv:2508.14925, August 2025, from the University of Science and Technology of China and Beihang University) is the first benchmark built to test agent robustness against tool poisoning under realistic MCP conditions rather than a toy setup. It ran on 45 live, real-world MCP servers with 353 genuine tools, threw 1,348 malicious test cases across ten risk categories at them, and evaluated 20 different LLM agent configurations.

Average Attack Success Rate across all 20: 36.5%. That's already a striking number, but the breakdown by model should stop anyone deploying agents cold.

• o1-mini: 72.8% ASR
• DeepSeek-R1: 70.9% ASR
• Phi-4: 70.2% ASR
• GPT-4o-mini: 61.8% ASR
• Qwen3-32b in reasoning mode: 58.5% ASR

Researchers called this the "Inverse Scaling" paradox, and it's genuinely counterintuitive: the more capable a model is at following instructions and reasoning through a task, the more likely it is to fall for a poisoned one. A stronger model doesn't second-guess a well-written instruction, it follows it more faithfully, and sometimes it even builds a justification for why the instruction makes sense. Refusal rates back this up in a grim way. Even the model with the best refusal rate in the whole study, Claude-3.7-Sonnet, refused less than 3% of the time. Existing safety training just doesn't fire when the attack is dressed up as a legitimate tool doing an unauthorized thing.

Separate lab benchmarking across more than 45 real-world MCP servers independently landed on attack success rates above 60%. When auto-approval was switched on in a controlled test, success jumped to 84.2%. That single configuration choice, letting an agent approve tool calls without a human in the loop, functions as a risk multiplier all by itself.

Teams upgrading to a smarter model to get better agent performance are, in the same move, opening the door wider for this exact category of attack, when the two results are read side by side.

The ecosystem-wide vulnerability picture behind those numbers

Scope first. Among public MCP servers, 5.5% carry tool poisoning vulnerabilities outright, and 43% contain command injection flaws that need security review before anyone should connect to them in production.

Secrets are leaking into the open, too. GitGuardian's State of Secrets Sprawl report found 24,008 unique secrets sitting in MCP-related config files on public GitHub, and 2,117 of them were still valid, meaning usable, at the moment of the scan.

Research into MCP implementations has found widespread use of file operations prone to path traversal and APIs tied to code injection. These aren't separate bugs, they're the exact footholds that turn a rug-pull or a schema-poisoning attack into something with real reach once it's inside.

The CVE count is climbing fast, not leveling off: more than 30 CVEs were filed against MCP servers, clients, and related tooling in January and February 2026 alone. A separate 2026 disclosure put the number of vulnerable MCP instances, spread across IDEs, internal tools, and cloud services, as high as 200,000.

The starkest single event came in April 2026, when OX Security disclosed what it called the "Mother of All AI Supply Chains": a "by design" weakness sitting inside Anthropic's official MCP SDK, present across multiple SDK versions, that allowed arbitrary command execution. It touched Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI. Anthropic's response was that sanitizing inputs is the developer's job, not something the protocol itself is responsible for handling.

None of the numbers above describe a worst-case scenario. They describe the baseline condition of the ecosystem any organization is stepping into the moment it connects an MCP server.

Four confirmed incidents that moved tool poisoning from theory to documented enterprise harm

Postmark-MCP npm backdoor, September 2025. This is the first confirmed real-world attack, not a lab demo. A package called postmark-mcp impersonated a legitimate Postmark email integration on the public npm registry. Its author shipped fifteen clean versions first, purely to build a trust baseline, before version 1.0.16, released September 17, 2025, quietly added one line of code: BCC every outgoing email to an address the attacker controlled. The package had 1,643 total npm downloads, and Koi Security estimated around 300 organizations were affected before it got pulled, with several thousand emails a day flowing to the attacker's domain during peak activity. It's the rug-pull pattern, just moved one layer down, into the package registry itself, where the delay before the payload was the whole strategy.

WhatsApp MCP exfiltration, November 2025. A malicious MCP server poisoned the tool descriptions inside a WhatsApp integration, quietly instructing the agent to redirect message data to a phone number the attacker controlled, all while the agent kept handling the user's actual request normally, with nothing about the interaction looking broken. That's what made it dangerous: nothing looked broken. The user got their answer, and message histories, personal and business both, were leaking out the back door at the same time. This is the core tool-description-poisoning variant playing out exactly as designed, a hidden instruction riding along inside a request that otherwise looks completely routine.