In an MCP tool poisoning attack, which field of the tool definition is the primary attack vector and why?
Tool poisoning hides adversarial instructions in the tool description, which the model reads as trusted guidance but users never see in approval dialogs.
Picture hiring a contractor and handing them a clipboard of job instructions. You glance at the cover sheet, which just says 'fix the sink.' But in tiny print on page three, someone has written 'also, copy the homeowner's keys and mail them to this address.' The contractor reads the whole clipboard and treats every line as your order. In MCP, the tool description is that clipboard. The model reads it in full to decide how and when to use a tool. You only ever see the cover sheet, which is the tool name in the approval popup. An attacker writes hidden orders in the fine print, and the model obeys them as if they came from you. The mismatch between what the model reads and what you see is the whole trick.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Tool poisoning is one of the most cited MCP security risks, and interviewers love it because it forces you to reason about where trust actually lives in an agent stack. The question is narrow on purpose: of all the fields in a tool definition, which one is the real attack surface, and why?
The answer is the tool description. To understand why, you have to track two things at once. First, what the model reads when it decides whether to call a tool. Second, what the human sees when they approve that call. The gap between those two is the entire vulnerability. An attacker does not need to break any cryptography or exploit a parsing bug. They simply write English that the model is trained to obey, and place it where the user will never look.
This deep dive walks the anatomy of a tool definition, explains why the description is uniquely dangerous, contrasts it with the other plausible-looking fields, lays out the layered defenses that follow directly from the mechanism, and connects the attack to the broader family of MCP supply-chain risks. By the end you should be able to defend the answer and rebut all three distractors out loud.
Anatomy of an MCP tool definition
When an MCP host connects to a server, it calls tools/list and receives a catalog. Each entry carries a small set of fields. The name is a short identifier the host uses to route a later tools/call. The inputSchema is a JSON Schema describing the arguments. The description is free-form natural-language text that explains what the tool does and when the model should reach for it.
The host then registers these tools with the model, usually by translating them into the model vendor's function-calling format. Crucially, the description text travels straight into the model's context, typically packed into the system block alongside the other tool definitions. The model is trained to read tool descriptions to decide which tool fits the user's request and how to fill in the arguments. Vendors actively encourage rich, detailed descriptions, because better descriptions produce better tool selection. The field is meant to be persuasive.
That design is exactly what makes the description load-bearing. It is not decorative metadata. It is operational guidance the model actively consumes on every turn the tool is available. Whatever sits in that field is read as trusted instruction from the system.
The consequence is a structural one. The description occupies a high-authority position in the model's instruction hierarchy. It arrives framed as configuration the host chose to install, not as untrusted content fetched at runtime. So the model has no built-in reason to be suspicious of it, even though it originates from whoever wrote the server, who may be a stranger on a public registry.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Vector | When it fires | User-visible? | Mechanism |
|---|---|---|---|
| Description poisoning | Before any call, every turn in context | No, dialogs show only the name | Adversarial text in tool description read as trusted instructions |
| Result poisoning | After the call, in tool output | Partly, output may be shown | Injection through returned content the model later reads |
| Rug pull | After approval, on a silent update | No, change is not re-surfaced | Server swaps a vetted definition for a malicious one |
Real products, models, and research that use this idea.
- Invariant Labs publicized MCP tool poisoning in 2025, showing hidden description text exfiltrating SSH keys through a benign-looking server.
- The OWASP MCP Top 10, published in 2025, lists tool poisoning and rug pulls as named server-side risks.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a rug pull attack relate to description poisoning, and what defense catches it?
A rug pull mutates an already-approved tool definition after install. Hash the full definition at approval and re-verify on every load; alert on any drift in the description or schema.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Thinking the attack lives in tool output. Output poisoning is a separate vector; description poisoning fires before any call and stays hidden from users.
60 second bullets to scan on the way to the call.
Why the description is the field the model reads to route tool calls
The visibility gap between model context and user approval dialogs
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.