How an MCP Tool Poisoning Attack Works

Q: How do I read an MCP tool's description before installing it?

You can list a server's tools and read the description field for each one, either through your client's tool or connector panel if it exposes full descriptions, or by querying the server directly and reading the tools/list response. Read the whole field rather than the first line, since the useful-looking summary is usually at the top and anything hidden sits below it.

An MCP tool poisoning attack does not arrive in anything you type. It arrives in the paperwork: the short description attached to a tool your AI agent already has permission to use. You approved that tool once. The instructions inside it can change later, and in most setups, nothing asks you again.

That gap between when you approved something and what it says now is the whole attack. It is also why “only install tools you trust” turns out to be weaker advice than it sounds.

Inside an MCP tool poisoning attack: a finance workflow walkthrough

On June 30, 2026, Microsoft Incident Response published a walkthrough of this pattern. Be precise about what it is: an attack pattern the team mapped out, not a disclosed breach at a named company. Microsoft credits the underlying technique to Invariant Labs, who first disclosed it in April 2025, and says it has been “observed in 2026 against a growing range of enterprise agents.”

The setup is a finance team’s assistant with three connections: a vendor database, an email connector, and a third-party invoice enrichment tool. That third tool was reviewed by a service owner and approved for production. No separate security review happened.

Then the developer of the enrichment tool pushed an update. The tool’s name stayed the same. The summary the team could see stayed the same. Only the description changed, and buried in what looked like formatting guidance was an instruction telling the agent to pull the last thirty unpaid invoices, summarize them, and attach that summary to the enrichment call, presented as a fraud-checking requirement.

An analyst asked a routine question about a supplier. The agent answered it correctly. It also collected thirty invoices and shipped them out as part of a normal-looking API call, and the response came back clean. Every single step was inside the agent’s permissions.

Microsoft’s own summary of why this works is the sentence to remember: “The vulnerability is not in any single system; it is in the trust boundary between them.”

Same tool, same name, new instructions

Most approval processes assume software announces itself when it changes. You review a vendor, you sign something, you move on. A tool description does not work that way. Microsoft describes the middle step as silent re-trust: where description changes do not trigger a re-approval workflow, “the updated instructions become active without additional review.”

The same MCP tool shown before and after an update, with an identical name and summary but a changed description carrying hidden instructions, the core of an MCP tool poisoning attack

The two things a human looks at, the name and the summary, are the two things the attacker leaves alone.

Here is the part that makes this hard to reason about. The description is not documentation sitting in a file somewhere. It is the text the agent reads to decide whether and how to use the tool, so it lands in the model’s working context before any call is made. A poisoned description does not need its own tool to be invoked to have an effect.

And the model has no way to tell where any of it came from. In Microsoft’s words, the agent “cannot distinguish between a legitimate instruction authored by its owner and a malicious instruction inserted by an upstream maintainer.” Both arrive as text. Both read like guidance.

You can check this on your own machine in about ten seconds, and the result is the point. Open the tool permissions for any connector you have enabled. You will get a list of readable names, a count, and a permission control. What you will not get is the description attached to any of them.

Tool permissions for one connector, listing fourteen read-only tool names with an always allow setting and no tool descriptions shown

Fourteen tools from one connector, each carrying a description this screen does not show. The permission applies to the group, not to what any individual tool tells the model to do.

Tool poisoning vs prompt injection: where the definitions split

Search for this term and you will find people describing three different attacks under one label. They are related, but if you are trying to decide what to check on Monday morning, the difference matters.

Poisoning the description before you install

This is the original version, demonstrated by Invariant Labs in April 2025: a tool that looks harmless, carrying hidden instructions from the moment you connect it. Our guide to MCP server security risks walks through their example in detail, so this post will not repeat it.

Poisoning the description after you approve it

Microsoft’s pattern above. The install was clean. The change came later, through an update channel that had no reviewer attached to it.

Poisoning the response at runtime

An OWASP community attack page describes a third route, where the tool’s replies carry the payload rather than its metadata. That page puts the root cause well: “Tool descriptions are reviewed once, when the agent first connects to a server. Tool responses go straight into the LLM context with no equivalent check.”

OWASP’s draft MCP Top 10 covers all three under MCP03:2025, defining tool poisoning as an adversary who “compromises the tools, plugins, or their outputs that an AI model depends on.” That list is still at beta stage rather than a finished standard, which is a fair reflection of how new this whole category is.

All three are prompt injection in the sense that matters: untrusted text reaching a model that treats it as instruction. What changes is the delivery route. If you have read direct vs indirect prompt injection, think of tool poisoning as indirect injection aimed at a channel that was never presented to you as content.

Stronger models fall for it more often

The intuitive assumption is that a smarter model would notice something was off. Tested at scale, it goes the other way.

MCPTox, a benchmark published in August 2025, built 1,312 malicious test cases across 10 risk categories on top of 45 live MCP servers and 353 real tools, then ran them against 20 LLM agents. The highest attack success rate belonged to o1-mini, at 72.8 percent. That figure is one model’s result, the worst of the twenty, not an average across the ecosystem.

Two findings from that paper are more useful than the headline number. First, the researchers found that “more capable models are often more susceptible, as the attack exploits their superior instruction-following abilities.” Being good at following instructions is the vulnerability. Second, refusal was close to absent: the best refusal rate in the group, from Claude-3.7-Sonnet, was still under 3 percent.

Read those together and a common assumption falls apart. Waiting for models to get good enough to spot this is not a plan.

Reading the MCP spec: SHOULD, not MUST

It would be easy to read all of this as a protocol flaw. The spec is more honest than that, and reading the actual text is clarifying.

MCP does have a mechanism for tools changing. Servers that declare the listChanged capability SHOULD send a notification when their tool list changes. The spec also tells clients they MUST treat tool annotations as untrusted unless they come from a trusted server, says there SHOULD always be a human able to deny a tool invocation, and lists validating tool results before passing them to the model as something clients SHOULD do.

Notice which word is doing the work. The strong requirement covers annotations. Everything protecting you from a changed description or an unvalidated response is a recommendation, and recommendations are implemented unevenly. The OWASP community page makes the same point about responses: the spec “advises clients to consider trust boundaries, but does not mandate response validation before passing content to the LLM.”

So the honest summary is that the protocol left these decisions to clients, and clients vary. Your exposure depends less on MCP than on which client you run and how you configured it.

Shrink the blast radius before you audit every tool

Reading every description of every tool you install is good advice that almost nobody sustains. These are the moves that keep working when the audit slips.

Treat a description like a system prompt

This is Microsoft’s framing and it is the single most useful reframe here. If you would want to know when your agent’s system prompt changed, you want to know when a tool description changed, because the model consumes them the same way.

Put a human in front of irreversible actions

The finance walkthrough ends with data leaving the building. A poisoned description can only cause what the agent is permitted to do, so the ceiling on the damage is the permission set, not the cleverness of the attack. Limiting AI agent permissions covers how to draw that line, and the short version is to gate what cannot be undone rather than confirming everything.

Know what is connected before you try to review it

You cannot review a list you do not have, which is the problem shadow MCP servers creates. Start there if your answer to “which tools does our agent have?” is a guess.

Be deliberate about always-allow

Turning off per-call confirmation is the setting that converts a poisoned description into a silent action. Keeping it on for scoped, reversible work is reasonable. Leaving it on everywhere means you have opted out of the one checkpoint the spec asks clients to provide.

FAQ

Can a poisoned MCP tool affect me if I never call it?

Yes, potentially. The description is the text your agent reads to decide whether and how to use a tool, which means it enters the model’s context as soon as the tool is available, not when you invoke it. A hidden instruction in an unused tool’s description can still shape how the agent uses a different, legitimate tool. This is why the number of connected tools matters, not just the number you use.

Can a scanner detect a poisoned tool description?

Partly. Scanners can flag imperative language sitting in a documentation field, and Microsoft’s guidance is to inspect tool metadata for exactly that. What no scanner does reliably is judge intent in free text, which is why the same guidance pairs inspection with change review and approval gates rather than treating detection as the control. Treat a scan result as a prompt to look, not as a verdict.

Does “always allow” mode make tool poisoning worse?

It removes the step where a person could catch it. The MCP specification says there should always be a human able to deny a tool invocation, and always-allow is the setting that waives that. It does not create the vulnerability, but it converts an attempted action into a completed one with no visible moment in between.

How do I read an MCP tool’s description before installing it?

You can list a server’s tools and read the description field for each one, either through your client’s tool or connector panel if it exposes full descriptions, or by querying the server directly and reading the tools/list response. Read the whole field rather than the first line, since the useful-looking summary is usually at the top and anything hidden sits below it.

Sources

Microsoft’s finance scenario is an attack pattern published by Microsoft Incident Response, not a disclosed breach at a named organization. MCPTox figures are from the August 2025 paper; the 72.8 percent result is the highest of the twenty agents tested, not an average. The OWASP MCP Top 10 was at beta stage when this was written.