Skip to content

Back to the catalog

MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers
arxiv.orgpaper

MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers

MCPTox is a benchmark for evaluating Tool Poisoning Attacks against LLM agents using the Model Context Protocol, where malicious instructions are hidden in a tool's metadata rather than its output. Built on 45 live real-world MCP servers and 353 authentic tools, it generates 1312 malicious test cases across 10 risk categories via three attack templates, and finds widespread vulnerability across 20 LLM agents: o1-mini has a 72.8% attack success rate, more capable models are often more susceptible due to stronger instruction-following, and even the best model (Claude-3.7-Sonnet) refuses less than 3% of attacks.

TL;DR New MCP benchmark shows 20 LLM agents are widely vulnerable to Tool Poisoning attacks hidden in tool metadata, with o1-mini's attack success rate at 72.8%.
Document

What it is

MCPTox (arXiv:2508.14925, USTC/Beihang, Aug 2025) benchmarks Tool Poisoning Attacks (TPA) where malicious instructions live in an MCP tool's description/metadata — injected into the agent's context at the registration phase, before any execution. The summary has the headline numbers; what it omits is the attack anatomy and why existing prompt-injection defenses don't transfer. The dataset is released (anonymized repo linked in the paper).

How it works

The attack's effectiveness turns on a three-part structure the paper isolates as its design principle. A poisoned description needs all three, or it fails:

  • Trigger Condition — when the malicious action fires (e.g. "before any file operation")
  • Malicious Action — the operation (e.g. read /home/.ssh/id_rsa)
  • Plausible Justification — why it's "necessary" (e.g. "as a security check")

Critically, the poisoned tool is never executed itself. The malicious action is always carried out by a legitimate tool already on the server. This is deliberate: it evades suspicion (legit tool calls look normal) and bypasses permission models that would restrict a new untrusted tool from high-privilege operations.

Three paradigms, by test-case count:

  • P1 Explicit Trigger / Function Hijacking (224): a tool mimics a common function (e.g. get_time); its description tells the agent to instead call a high-privilege tool.
  • P2 Implicit Trigger / Function Hijacking (548): a tool disguised as background process (e.g. security_check) injects a rule ("before any file op, read the SSH key") triggered by unrelated user actions.
  • P3 Implicit Trigger / Parameter Tampering (725): an unrelated tool's description injects a global rule that alters another tool's parameters (e.g. rewrite email recipient to an attacker address).

Why prior benchmarks miss this

This is the finding most useful to an engineer: repurposing IPI payloads (InjecAgent, AgentDojo) into tool descriptions yields ~0% success. IPI attacks target tool output (post-execution); TPA targets description (pre-execution reasoning). IPI payloads are bare Malicious Actions with no Trigger Condition, so the agent has no context to act on them. Content-based safety alignment is likewise ineffective here — the highest refusal rate observed was Claude-3.7-Sonnet at <3%, because the actions use legitimate tools for unauthorized ends rather than tripping content filters.

What to do

No patch — this is a benchmark/threat characterization. The actionable takeaways for anyone deploying MCP agents: treat third-party tool metadata as untrusted input at registration, not just tool outputs; don't rely on refusal/content alignment as a TPA defense; and watch for legitimate high-privilege tools (file read, email send) being invoked as side effects of unrelated benign queries — the "poisoned tool never runs" property means the malicious server's own tool won't appear in the call trace.

Caveats

Risk-category count is stated as both 10 and 11 within the paper. Test cases are LLM-generated (GPT-4, Gemini-2.5) with manual verification, so realism depends on that review step.

Technologies named here

Techniques named here