MCP Tool Poisoning: Security Risks of Tool Descriptions, Tool Results, and Rug Pulls

MCP tool poisoning is SSA descriptive wording for a security-relevant change to the state an agent reads to decide what a tool does and what a tool call returned: a tool's name and description at connection time, the definition a server serves after that description was approved, or the content embedded in a tool's result. The defining cause is adversarial. A tool description that is merely badly written, or a tool result that is merely wrong, is a different problem, covered below.

What it is

The defining object is tool and environment state: the metadata and observations an agent treats as trusted operating context rather than as content requiring separate verification. This includes the tool description shown at approval time, the live definition a server actually serves on each call, and the data a tool call returns. The defining cause is a party who controls or compromises a description, a server, or fetched content, and uses that position to have hidden instructions read as operating instructions rather than as data. The defining consequence is that the agent's tool selection, parameters, or authorized action changes because it trusted poisoned tool state, not because the user's own instruction changed.

What it is not

A tool description that is inaccurate or incomplete with no adversary — an integration-quality problem, not this working term.
A tool call that fails or returns wrong data from an ordinary bug or outage, with no evidence of deliberate manipulation.
Prompt injection carried purely through user-supplied chat text with no tool description, server, or result in the chain, covered by agent state attack's broader definition instead.
Model-weight attacks, training-data poisoning, and reproducible exploit payloads.

In scope

Hidden instructions in a tool's name, description, or parameter schema, read by the model but not shown in the approval view.
A server that serves a different, malicious definition after a client approved an earlier, benign one — a rug pull.
A malicious or compromised MCP server package distributed through a public registry, so every installer inherits the poisoned state.
Content embedded in a tool call's result, such as a fetched issue or file, that an agent reads as an instruction rather than data.
Defensive controls for provenance, pinning, isolation, and recovery of tool and environment state.

Target state, trust boundaries, and impact

The target state sits at the tool boundary: the description a client displays for approval, the definition a server actually returns at call time, and the payload a tool call hands back to the model. MCP's own security guidance treats tool descriptions as untrusted input by design and places enforcement on the host application, not the protocol (Model Context Protocol, Security Best Practices). What matters is whether an approval made once, at install time, is re-verified against what the server serves later, and whether results are separated from operating instructions before reaching the model's context.

Three preconditions are usually present: an adversary needs a position to write a description, compromise a server, or influence fetched content; the client must accept that content without independent inspection after approval; and the agent must act on it, most often through an unintended tool call. Resulting effects include exfiltration of credentials or message histories through side channels the user did not request, unauthorized tool invocations that bypass an application's own permission checks, and compromise persisting across every session that reconnects to a poisoned server.

Persistence

A single poisoned tool result affects the turn that read it. A poisoned description or a rug-pulled definition persists for as long as the client keeps the connection approved, affecting every session that reuses that approval — session to cross-session persistence rather than a single turn.

What the research establishes

Invariant Labs disclosed the technique on 2025-04-01, coining it a Tool Poisoning Attack: "seemingly innocent tools contain hidden malicious instructions" that manipulate an agent without user awareness. Their proof of concept hid instructions in `<IMPORTANT>` tags inside an ordinary `add` tool's description, directing Cursor to read `~/.ssh/id_rsa` and exfiltrate it through a tool parameter while presenting an innocuous explanation to the user; a second experiment hijacked a separate, trusted `send_email` tool to reroute outgoing mail. The same post names the rug pull directly: "a malicious server can change the tool description after the client has already approved it" (Invariant Labs, MCP Security Notification: Tool Poisoning Attacks).

On 2025-05-26, Invariant Labs disclosed a structurally different case against GitHub's official MCP server: an attacker files a public issue containing a prompt injection payload, and when a user asks their agent to review issues, the agent fetches that content as a tool result, is redirected into reading private repositories, and exfiltrates data through a pull request the attacker can read. The researchers called this "a fundamental architectural issue" rather than a code flaw, since agents cannot distinguish legitimate from malicious information arriving through a legitimate tool channel (Invariant Labs, GitHub MCP Exploited) — the tool-result entry path rather than the description path.

The supply-chain variant reached production: on 2025-09-25, Postmark disclosed that a counterfeit npm package named `postmark-mcp` built credibility over fifteen releases before version 1.0.16 added a backdoor that silently BCC'd every email the tool sent to an external address (Postmark, Security Alert: Malicious postmark-mcp npm Package). This article does not reproduce any of the three techniques; it treats them as evidence that description, result, and distribution are distinct, already-exploited entry paths into the same target state.

Detection: observable signs

A tool's description, name, or schema differs between the version a user approved and the version the server currently serves.
A tool call's parameters or destination do not match what the user's visible instruction requested.
An agent's response text describes a benign action while the underlying tool call touches a different file, credential, or recipient.
A newly connected or updated server package has no verifiable maintainer history matching the brand it claims to represent.
Content fetched by one tool call is echoed back as an instruction governing a later, unrelated tool call.

Useful telemetry includes the tool description and schema at connection time diffed against the version served at call time, raw tool-call arguments kept separate from the model's narration, and provenance for any installed server package.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders, not a standard requirement or effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Description pinning and diffing | Rug pull after approval | MCP clients and hosts | Catches drift, not a description malicious from the first approval; pair with content inspection. | | Untrusted-content segregation for results | Fetched content becoming an operating instruction | Any tool that retrieves external content | Bypassable by encoding tricks; test with payloads that mimic the segregation markers themselves. | | Least-privilege, per-tool authorization | Poisoned state becoming an unauthorized action | Tool-using agents with sensitive access | Limits blast radius, not the belief; exercise deny paths for both poisoned-description and poisoned-result scenarios. | | Registry provenance and version pinning | A malicious package reaching new installers | Public MCP registries and package managers | A previously clean package can turn malicious at a later version, as in postmark-mcp; re-verify on every bump. |

Prevention should treat descriptions and results as untrusted input, not configuration. Detection should diff served definitions against approved ones. Containment should revoke the connection and quarantine state written under it before deleting evidence. Recovery should reinstall from a verified source, re-approve explicitly, and revalidate actions taken while the connection was live.

Boundaries with similar concepts

Instruction file poisoning targets files an agent loads at startup as standing guidance; this working term targets the tool layer specifically, though an MCP server manifest committed to a repository overlaps both. Shared state poisoning targets state more than one agent reads as trusted; a poisoned tool server matches that pattern once its output reaches more than one agent, but stays within this narrower path when only tool description and result state is affected. A tool that is merely unreliable, with no adversary and no hidden instruction, stays outside this working term.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | Invariant Labs (2025-04-01, 2025-05-26) | Tool Poisoning Attack; rug pull; GitHub MCP exploit | Documented named attacks across the description and result entry paths; direct evidence for this entry. | | Postmark (2025-09-25) | postmark-mcp malicious npm package | Documented supply-chain instance of the same target state reaching production users. | | OWASP MCP Top 10, 2025; OWASP Agentic Top 10 2026 | `MCP03:2025 Tool Poisoning`; `ASI02 Tool Misuse and Exploitation`; `ASI04 Agentic Supply Chain Vulnerabilities` | Standard-adjacent and agentic risk categories covering the description, result, and supply-chain paths (OWASP, MCP03:2025 Tool Poisoning; OWASP Top 10 for Agentic Applications 2026). | | MITRE ATLAS v2026.06 | `AML.T0110 AI Agent Tool Poisoning`; `AML.T0109 AI Supply Chain Rug Pull`; `AML.T0104 Publish Poisoned AI Agent Tool` | Attacker-behavior classification for tool metadata poisoning and post-adoption compromise (MITRE ATLAS; ATLAS release v2026.06). | | Agent State Attack | MCP tool poisoning | SSA descriptive phrase bundling the above under one target state, not attributed to the sources above. |

Related terms

Agent state attack: the SSA Working Term this article's scope sits under.
Instruction file poisoning: the adjacent state surface for standing configuration files rather than tool calls.
Shared state poisoning in multi-agent systems: the working term for state more than one agent or session reads as trusted.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping this entry draws its standards references from.

FAQ

Is "MCP tool poisoning" an official standard term?

Partially. OWASP's MCP Top 10 project names `MCP03:2025 Tool Poisoning` for the description and schema path, and MITRE ATLAS v2026.06 separately names `AML.T0110 AI Agent Tool Poisoning` and `AML.T0109 AI Supply Chain Rug Pull`. This article's title bundles the description, result, and rug-pull paths under one SSA-descriptive scope; cite the individual identifiers above to their own owners, not to this site.

Does re-approving a tool once make a connection safe going forward?

No. The rug pull documented by Invariant Labs, and the version-1.0.16 backdoor in postmark-mcp, both depend on exactly this assumption. A one-time approval verifies the definition at that moment, not the definition a server serves on a later call or a later package version.

Sources

Verification and change history

Standards and versions referenced: OWASP MCP Top 10, 2025 edition; OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30).

Last verified: 2026-08-18. The Invariant Labs publication dates, quoted definitions, and attack descriptions were read from the two primary posts; the Postmark incident details were read from Postmark's own security alert; the MCP security-guidance quote was read from the official specification site; the OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entries.

Change history: 2026-08-18, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** `MCP03:2025 Tool Poisoning` is an OWASP project term. `AML.T0110`, `AML.T0109`, and `AML.T0104` are MITRE ATLAS Standard Terms. "Tool Poisoning Attack" and "rug pull" as applied to MCP are Invariant Labs research/industry terms. "MCP tool poisoning" as the umbrella covering description, result, and distribution paths together is SSA descriptive wording, not a standard term.