MCP Tool Poisoning and Rug Pull Attacks

Last updated: November 4, 2026

What is MCP tool poisoning? MCP tool poisoning is an attack where a Model Context Protocol server hides malicious instructions in a tool's description, parameter schema or return values. The model reads that metadata as trusted context and follows it. Rug pulls and tool shadowing are close variants: one changes a tool after you approve it, the other uses one server to hijack another server's tools.

TL;DR: Key Takeaways

• In MCPTox, built on 45 live MCP servers and 1,348 malicious test cases, o1-mini reached a 72.8% attack success rate (MCPTox, 2025).
• The model with the highest refusal rate, Claude-3.7-Sonnet, still refused fewer than 3% of poisoned instructions, so model alignment is not a control on its own (MCPTox, 2025).
• A poisoned description can act before any tool is called, because the client puts it in the model's context when it loads the list (Trail of Bits, 2025).
• OWASP's MCP cheat sheet has 12 best-practice areas, and asks you to hash the complete tool definition, including schemas and annotations, and review any change (OWASP).
• Cursor up to 1.2.4 let an approved MCP configuration be swapped with no new prompt (CVE-2025-54136, NVD), and postmark-mcp 1.0.16 added a hidden BCC (Qualys, 2025).
• 55% of 100 surveyed CISOs already run MCP servers or other agent-to-application integrations in production (Andreessen Horowitz, 2026).

At a glance: four MCP tool attacks compared

Quick Answer

How do you stop MCP tool poisoning and rug pulls?

Treat every tool definition as untrusted input. Review the full definition before approval, hash and pin it, and block or re-approve the tool whenever the hash changes. Stop one server's descriptions from referencing another server's tools. Then inspect tool outputs at runtime, because pinning cannot see changes in server code.

How we researched

On November 4, 2026 we reviewed the OWASP MCP cheat sheet and Top 10, the MCP tools specification (2026-07-28), Trail of Bits, MCPTox, NVD record CVE-2025-54136 and the Qualys postmark-mcp report. The tables and playbook are our synthesis. We ran no new attack tests.

What is MCP tool poisoning?

MCP tool poisoning is a form of indirect prompt injection that lives in tool metadata instead of user input. OWASP defines it as malicious instructions hidden in tool descriptions, parameter schemas or return values that manipulate the model's behavior. It works because the model cannot tell a tool's documentation from an order.

The root cause is how MCP shares tools. A client asks each server for its tool list, and the client adds the names, descriptions and schemas to the model's context. According to Trail of Bits (2025), this lets a malicious server attack before any tool is invoked. It calls the flaw "line jumping." The OWASP MCP Top 10, still in beta, lists the risk as MCP03:2025 Tool Poisoning.

OWASP adds a detail many teams miss: the model sees the tool descriptions from all connected servers at once. One poisoned server can therefore influence how the agent uses every other tool in the session.

If you are new to the protocol, start with our MCP security guide. For the full list of risks, see our OWASP MCP Top 10 explainer, and for attacks that ride on tool output, our MCP prompt injection guide.

How tool description injection works

Tool description injection hides instructions in text the user rarely reads but the model always reads. The poisoned field can be the description, a parameter name, a parameter description or a nested schema. A typical payload tells the model to read a sensitive file, add data to a call, or keep the action secret from the user.

Here is a simplified, illustrative poisoned definition. The visible purpose is harmless, and the hidden instruction is the attack.

Three things make this hard to catch:

1. Interfaces often summarize. OWASP tells clients to show full parameters and the exact command without truncation, because a short summary can hide a long block of instructions.
2. The schema is attack surface too. OWASP says to treat the entire tool schema as a potential injection surface, not just the description. An extra optional parameter such as notes gives the model a quiet place to leak data.
3. Capable models comply. According to MCPTox (2025), more capable models are often more susceptible, because the attack exploits their stronger instruction following.

The defense starts before approval. Reject schemas that accept undeclared fields, and alert on text such as "ignore," "do not tell the user" or credential paths. OWASP is clear, in its guidance on tool return values, that tag stripping and pattern detection are only extra alerting measures. They cannot show that the remaining text is safe.

Rug pull attacks: when an approved tool changes after approval

A rug pull happens when a server changes its tool definitions after initial user approval, turning a trusted tool malicious. The server behaves well during review, earns its place on the allowlist, then swaps in a poisoned description, a new parameter or a flipped annotation later. Your approval was for a tool that no longer exists.

The protocol makes change normal, which is why it needs control. According to the MCP tools specification (2026-07-28), a server that declares listChanged should notify subscribed clients when its tool list changes. The list may also vary with the authorization presented. A client that silently accepts the new list has no approval boundary at all.

Two details make rug pulls worse than they look:

• Annotations change behavior without changing text. OWASP notes that a flipped readOnlyHint or destructiveHint can change client approval behavior with no visible description change. Clients must treat annotations as untrusted unless they come from trusted servers.
• Code can change behind a stable definition. OWASP stresses that hashing detects metadata changes, not changes to server code. A server can keep the same description and start returning poisoned output.

Both patterns have already happened outside the lab:

According to the National Vulnerability Database (2025), the Cursor flaw scores 8.8 (high) on CVSS 3.1, while GitHub as CNA scores it 7.2. According to Qualys (2025), reports put postmark-mcp at about 1,500 downloads a week before the maintainer removed it.

OWASP's rule of thumb is blunt: do not assume a tool approved yesterday is the same tool today. Re-prompt for consent when definitions change, and verify package integrity with checksums or code signing. Our guide to an MCP registry and allowlist shows how to build that approval flow.

Tool shadowing: when one MCP server hijacks another's tools

Tool shadowing, also called cross-origin escalation, is when a malicious server's tool description manipulates how the agent behaves with tools from other, trusted servers. The attacker never needs its own tool to be called. It only needs its description in the same context window as your email, payments or code tools.

A shadowing description might say that whenever the agent sends an email, it must also copy an external address. The trusted tool does the damage, and its logs look normal because the trusted server did what it was asked.

OWASP's controls for multi-server setups target this directly:

• Treat each MCP server as an untrusted, independent security domain.
• Prevent tool descriptions from one server from referencing or modifying the behavior of tools from another server.
• Monitor for cross-server data flows, such as credentials from server A appearing in calls to server B.
• Use an MCP proxy or gateway to enforce isolation policies between servers.

Names matter too. Tool names are unique only within one server, so the specification says clients that aggregate servers should disambiguate, for example by prefixing a server identifier. OWASP also advises keeping payment, authentication and personal data servers apart from general-purpose ones.

How to detect MCP tool poisoning and rug pulls

Detection works in layers: inspect definitions before approval, verify them on every refresh, and watch behavior at runtime. No single layer is enough. Pre-approval review misses rug pulls, pinning misses code changes, and runtime monitoring alone misses quiet metadata swaps.

The specification asks clients to show tool inputs before calling a server, validate results before passing them to the model and log tool usage for audit. OWASP adds alerts on new tools being called, admin-level queries and abnormal call frequency, backed by central logs.

Validation belongs in code, not in the prompt. OWASP advises strict JSON Schema for tool parameters, with additionalProperties: false and patterns on string fields, so only declared parameters and valid formats are accepted. That closes the "extra field" trick from the example above.

Pinning tool definitions: what it catches and what it misses

Pinning means recording a cryptographic hash of each reviewed tool definition and refusing to use the tool if the live definition no longer matches. It is the core defense against rug pulls, and OWASP recommends verifying the pin before each execution. Done well, it turns a silent change into a visible approval request.

To make pinning work in practice:

1. Hash the complete definition. Include name, title, description, inputSchema, outputSchema and annotations. Hashing only the description misses schema and annotation swaps.
2. Normalize before hashing. A canonical JSON form stops harmless key reordering from triggering false alerts.
3. Store the pin with context. Keep server, version, credential scope, reviewer and date next to the hash. A server may return different tools for different authorization, so it can legitimately have more than one pin.
4. Re-check on every refresh and fail closed. Tool lists can be cached, so verify the hash whenever the list reloads. On a mismatch, block the tool and request re-approval.
5. Pin the code too. Verify package versions with checksums or signatures, as OWASP advises.

That right-hand column is why pinning needs runtime inspection beside it. Our MCP security best practices checklist places pinning alongside sandboxing, least privilege and logging.

Security and governance: stopping tool poisoning at runtime

Tool poisoning is a runtime problem. The poisoned text arrives when the agent loads the tool list, the rug pull lands on a later update, and the shadowing instruction fires when a trusted tool runs. Policies written in a wiki do not see those moments. A control point in the path of every MCP connection does.

According to Andreessen Horowitz (2026), which surveyed 100 CISOs at companies with more than 1,000 employees, 46% cite agents exceeding their permissions or being compromised among their biggest worries. MCPTox (2025) shows why. Its headline results name o1-mini and Claude-3.7-Sonnet, so treat them as a baseline and retest on the model you run.

NeuralTrust approaches this as a Runtime Security Mesh. The Agent Gateway (TrustGate) puts model, MCP server, tool and agent calls behind one gateway. It adds per-agent and per-tool RBAC, end-user identity on every hop and cryptographic audit trails. Agent Runtime Security (TrustGuard) inspects requests and responses inline, including poisoned tool results, and can allow, block or transform them. AI Red Teaming (TrustTest) tests agents for indirect injection and tool abuse before release. NeuralTrust reports under 100 ms of added latency at p95 with PromptGuard and Data Masking enabled. The Free plan covers TrustGate and TrustGuard for 100,000 requests a month.

Which defense should you start with?

Start where your exposure is highest. Teams installing third-party servers need review and pinning first. Teams running many servers in one agent need isolation. Teams in regulated industries need the audit trail that proves the other controls worked. Most teams end up needing all three.

For remote servers, credential scope decides how much a poisoned tool can reach. Our MCP authentication guide covers OAuth and tokens.

Conclusion

MCP tool poisoning turns tool metadata into a command channel. Description injection plants the instruction, rug pulls deliver it after approval, and tool shadowing aims it at your most trusted tools. The fixes are known: review full definitions, hash and pin them, fail closed on change, isolate servers and inspect outputs at runtime. With benchmark refusal rates under 3%, put those controls where every MCP connection passes through them.

Secure MCP Tools in Production with NeuralTrust

Put every MCP tool call behind one gateway with per-tool access control, runtime inspection and a full audit trail.

Related Comparisons

• OWASP MCP Top 10
• MCP Security Best Practices
• MCP Prompt Injection
• MCP Server Registries and Allowlists

FAQs about MCP Tool Poisoning

1. What is MCP tool poisoning?

MCP tool poisoning is an indirect prompt injection where malicious instructions hide in a tool's description, parameter schema or return values. The client puts that metadata in the model's context when it loads the tool list, so the attack can work even if the tool is never called. Trail of Bits calls this line jumping.

2. What is an MCP rug pull attack?

A rug pull is when an MCP server changes a tool after you approved it, turning a trusted tool malicious. The change can be hidden text, a new parameter, a flipped annotation or new code. Hash and pin the approved definition, block the tool until someone re-approves any change, and verify package versions.

3. What is MCP tool shadowing?

Tool shadowing is when a malicious server's tool description changes how the agent uses tools from other, trusted servers. For example, it can tell the agent to copy an extra recipient on every email. The trusted tool performs the harmful action, so per-server isolation and cross-server monitoring are the key controls.

4. Does tool pinning stop all MCP tool poisoning?

No. Pinning detects changes to tool metadata after review, which stops definition-level rug pulls. It does not detect malicious server code behind an unchanged definition, poisoned tool outputs or a bad definition approved by mistake. Combine it with pre-approval review, verified package versions and runtime inspection.

5. Can the model itself refuse poisoned tool instructions?

Rarely. In the MCPTox benchmark, the model with the highest refusal rate refused fewer than 3% of tool poisoning attacks, and more capable models were often more susceptible. Treat model behavior as a bonus, not a control, and enforce authorization and validation in trusted code outside the model.

6. How is tool poisoning different from prompt injection in tool output?

Tool poisoning lives in the tool definition, which the model reads before or during tool selection. Prompt injection in tool output lives in the data a tool returns after a call, such as a web page or email. Both are indirect prompt injection, so treat definitions and outputs as untrusted.

About the Author

Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.

NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.

Sources

Accessed on November 4, 2026.

1. OWASP Cheat Sheet Series, "MCP Security Cheat Sheet".
2. OWASP, "MCP Top 10" (2025 beta).
3. Model Context Protocol, "Tools" (spec version 2026-07-28), 2026.
4. Trail of Bits, "Jumping the line: How MCP servers can attack you before you ever use them", April 21, 2025.
5. Wang et al., "MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers", arXiv, August 2025, revised September 29, 2026.
6. NIST National Vulnerability Database, "CVE-2025-54136", published August 2, 2025.
7. Qualys ThreatPROTECT, "Malicious MCP Server on npm postmark-mcp Exploited in Attack", September 30, 2025.
8. Andreessen Horowitz, "The New Security Agenda", 2026.
9. NeuralTrust, "Agent Gateway (TrustGate)" and pricing, product pages.