Originally published as part of VerifyClaw's internal security research into LLM-facing attack surfaces — adapted here for a general audience.
Every tool an MCP server exposes comes with a name, a description, and parameter docs — all of it model-visible text the agent reads before deciding what to call. Tool-definition poisoning embeds an instruction inside that description rather than inside a response, so the manipulation happens at planning time, before any tool has actually run.
Why it matters for MCP agents
This is a supply-chain problem, not a runtime one. The server doesn't need to misbehave once it's called — the poisoned text can already have redirected the agent toward calling the wrong tool, or the right tool with attacker-chosen arguments, purely by how convincingly its definition reads. A user auditing tool behavior in a sandbox can still miss this, because the attack surface is the catalog entry, not the execution.
How we study it
The relevant comparison is between a benign tool definition and a modified one, holding the user's actual task fixed, and measuring the likelihood the model assigns to naming one tool over another at the decision boundary — plus what it actually generates. This is exactly the class of technique our SAF-MCP audit's static and sandboxed-live checks are built around: 86 techniques that include probing whether a server's own tool descriptions carry planning-altering language, not just whether its code does something obviously destructive.
Related reading
- How We Test MCP Servers with 86 Attack Techniques
- We Found a Security Scanner That's Actually a Trojan
A full SAF-MCP audit checks a server's tool definitions, not just its runtime behavior — see our pricing on the docs page.