MCP tool poisoning: why an allowlist beats a scanner
A peer-reviewed benchmark across 45 live MCP servers found that more capable models are more vulnerable to tool poisoning, not less — the attack exploits the same instruction-following that makes them worth using. That finding rules out most of the obvious defences.
The Model Context Protocol solved a real problem. Before it, every agent framework wired up tools its own way; now there's a standard for discovering and calling them, and an ecosystem of servers you can point an agent at. The cost of that convenience is that the tool catalogue became untrusted input — and the agent reads it during planning, before anything executes.
Tool poisoning is the attack that follows. Malicious instructions go into a tool's metadata — description, parameter docs, schema annotations — rather than its output. The agent absorbs them while working out what the tool does. Nothing needs to run.
What the benchmark found
MCPTox (AAAI, peer-reviewed) is the first systematic evaluation of this in realistic conditions: 45 live real-world MCP servers, 353 authentic tools, 1,312 malicious test cases across three attack templates and ten risk categories, run against 20 prominent LLM agents.
Three results matter, and the second one is the important one.
| Finding | Why it matters |
|---|---|
| Attack success rates up to 72.8% (o1-mini) | Not a marginal or theoretical vulnerability — a majority-of-the-time outcome on real servers |
| More capable models are often more susceptible | The attack exploits superior instruction-following. Upgrading the model is not a mitigation, and may be a regression |
| Indirect-prompt-injection payloads score ~0% when reused here | Tool poisoning is a distinct attack class; defences tuned for injection in tool output don't transfer |
The middle row is the one that should change your plan. The usual response to a model-layer weakness is "this will improve with the next generation." Here, the property being exploited — reading instructions carefully and following them faithfully — is the property you're paying for. A model that's better at understanding a tool description is better at understanding a poisoned one.
Why scanning is the losing side of this trade
The intuitive defence is to inspect tool descriptions before trusting them: look for override phrasings, instruction-like text, suspicious imperatives. It's the same instinct behind prompt-injection filters, and it has the same structural weakness.
Scanning asks does this look malicious? — a judgement about text the adversary authored, can iterate on, and can test against your filter until it passes. You're on the wrong side of an asymmetry: they need one phrasing that works, you need every phrasing to fail.
The supply chain case makes it worse. In February 2026, a trojanized MCP server for the Oura Ring was submitted to a legitimate registry — functionally identical to the real one, carrying an infostealer that exfiltrated browser passwords, cloud session tokens, SSH keys, and API keys. There was no suspicious description to find. The metadata was fine. The package was the problem.
What an allowlist changes
Deny-by-default asks a different question: is this tool one of the ones this agent may call? The adversary has no input into the answer. They can write the most persuasive tool description ever composed and it doesn't matter, because the agent was never permitted to call that tool.
server exposes : 47 tools
policy permits : read_calendar, create_event, list_attendees
reachable : 3
The other 44 are unreachable regardless of what
their descriptions say. No judgement call required.This is the same move as deny-by-default anywhere else in infrastructure, and it works for the same reason: the decision depends on your configuration rather than on the attacker's creativity. Pair it with argument-level policy — a tool may be allowed while a specific argument range isn't — and the reachable surface gets smaller again.
MCP standardises tool discovery, not authorisation, which is why this has to come from a layer above the protocol.
What an allowlist does not do
It detects nothing. This is the honest limit and it's worth being direct about, because it's where this category usually overclaims.
If the poisoned tool is one you allowed, you are exposed exactly as much as you would have been without the allowlist. The Oura Ring case is precisely this scenario: a legitimate-seeming tool you had every reason to permit. Deny-by-default shrank the blast radius of everything else on that server and did nothing about the tool you wanted.
The controls for that problem are upstream and they aren't runtime policy: signing and verifying server packages, pinning versions rather than fetching latest, treating the registry as a supply chain with provenance requirements, and reviewing what a new server actually does before you point an agent at it. This maps to ASI04 in the OWASP agentic top 10, where we score ourselves partial for exactly this reason.
And none of it addresses what happens after a permitted tool returns. Content coming back from an MCP server is still untrusted input that can carry an injection into memory or into the next planning step — a separate problem needing provenance tracking rather than an allowlist.
The practical shape
Nothing here is exotic. In rough order of leverage: enumerate the tools each agent actually needs and permit only those; constrain arguments where the tool is powerful and the safe range is narrow; require approval for anything that writes to a production system; pin and verify the servers themselves; and keep a record of every call so that when a server turns out to have been compromised three weeks ago, you can answer what it was asked and what it returned.
The last one gets skipped most often and matters most in the aftermath. Prevention narrows what can happen; the log is what tells you what did.
Frequently asked questions
What is an MCP tool poisoning attack?
Malicious instructions embedded in a tool's metadata — its description, parameter docs, or schema annotations — rather than in its output. The agent reads the tool catalogue during planning, absorbs the injected instruction as part of understanding what the tool does, and acts on it. Nothing needs to execute for the attack to land, which is what separates it from ordinary indirect prompt injection.
Are more capable models better at resisting tool poisoning?
No — the MCPTox benchmark found the opposite. More capable models are often more susceptible, because the attack exploits exactly the instruction-following ability that makes them useful. A model good at reading a tool description carefully and doing what it says is good at reading a poisoned one carefully and doing what it says. Waiting for a better model is not a mitigation strategy here.
Why is an allowlist better than scanning tool descriptions?
Scanning asks "does this description look malicious?", which is a judgement call about adversary-authored text that the adversary gets to iterate on. An allowlist asks "is this tool one of the three this agent may call?", which the adversary has no influence over. The second question stays answerable when the attacker is more creative than your patterns.
Does an allowlist stop a compromised MCP server entirely?
No, and this is the honest limit. An allowlist reduces reach — if a server exposes forty-seven tools and policy permits three, the rest are unreachable. It does not detect compromise. If the poisoned tool is one you allowed, you are exposed. In February 2026 a trojanized MCP server was published that was functionally identical to the legitimate one; an allowlist naming that tool passes it through unchanged. Signing, pinning, and registry provenance are the controls for that, and they live upstream.
Is tool poisoning the same as indirect prompt injection?
Related but distinct, and the MCPTox authors demonstrated the difference empirically: repurposing payloads from indirect prompt injection benchmarks into tool descriptions produced an attack success rate of nearly zero. Payloads that work against one do not transfer to the other, which means a defence tuned for injection in tool output is not automatically a defence for poisoning in tool metadata.