A **rug pull** is when an MCP server is benign when you first approve it, then quietly changes a tool's behavior later. The name comes from the picture: the ground is pulled out from under you after you trusted it.
The reason MCP cannot stop this is simple. When a server returns its tool list, each tool has a name, a description, and an argument schema. There is no version number, no cryptographic hash, and no signature on any of that. So when the server returns a different description next time, nothing in the protocol marks it as changed.
The host approved the tool once based on the original description. MCP defines no event that says 'this tool changed, ask the user again'. The host has no built-in way to compare the new definition against the one you approved.
That gap is a design choice, not a bug. The spec leaves integrity and re-approval to the host implementation. So defenses like pinning a hash of each tool definition live in the client, not the protocol.
A **rug pull** exploits a trust on first use gap. You approve a server's tools once. The server later returns altered definitions under the same names, and nothing flags the change.
MCP cannot prevent this because the spec carries no integrity metadata on tool definitions. The `tools/list` response has a name, a description, and an input schema. It has no version field, no hash, and no signature. So the host cannot prove the tool it calls today matches the one the user approved yesterday.
There is also no protocol event for definition drift. The spec defines a list-changed notification, but that only tells the host to refetch. It does not force re-approval or diff the change. A host that blindly refetches and trusts the new list walks straight into the trap.
The fix lives at the host layer. Pin a hash of each approved tool definition. Recompute it on every connection and on any change notification. If the hash differs, block the tool and re-prompt the user. Pair that with version pinning, a preference for trusted or local servers, and human approval on sensitive calls.
Quick reference
TL;DR
MCP has no version, hash, or re-approval signal on tool definitions, so a server can silently swap a benign tool for a malicious one after you approved it.
Imagine hiring a contractor based on a written job description you signed off on. A rug pull is the contractor quietly rewriting that description after you approved it, so 'paint the fence' now reads 'also copy the house keys'. You never see the new version because nobody made you re-sign. MCP works the same way. A server tells the host what its tools do, you approve them once, and the server can later return a different description under the same name. The protocol has no signature, no version number, and no checksum on those descriptions. So the host has no built-in way to notice the swap and ask you to approve again.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Local stdio servers running only code you build and version yourself There is no untrusted publisher in the loop, so heavyweight signing or pinning adds friction with little marginal safety.
Read-only tools with no side effects and no sensitive data access A mutated definition can still mislead the model, but forced re-approval on every change may cost more than the low blast radius justifies.
Prototyping or internal tooling behind a trusted network boundary Supply chain hardening matters most for third-party remote servers; early internal work can defer it without real exposure.
Quick scan · 2–4 min
Everything important, quickly.
5 min: define rug pull, show the missing integrity fields in a tools list entry, explain why OAuth and initialize do not help, then walk host-side hash pinning, version pinning, and re-approval as the real defenses.
Side-by-side
Control
What it authenticates
Stops a rug pull?
OAuth 2.1 token
The server or principal identity
No, identity is fine; the definition changed
initialize handshake
Connection setup and capabilities
No, definitions can change after it
list-changed notification
That the list changed, not whether it is safe
No, only triggers a refetch
Host-side definition hash pinning
Tool definition integrity over time
Yes, detects the swap and re-prompts
Real-world examples
Real products, models, and research that use this idea.
1Anthropic's MCP spec defines a tools list-changed notification for refetch, but leaves integrity checking and re-approval entirely to the host client.
2Invariant Labs demonstrated MCP tool poisoning and rug pull style attacks in 2025, hiding malicious instructions inside tool description metadata.
3The OWASP MCP Top 10, published in 2025, lists rug pull and tool poisoning as distinct supply-chain risks for MCP deployments.
4The proposed ETDI extension adds cryptographic signing and versioning to tool definitions, addressing exactly this gap outside the core spec.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you implement host-side hash pinning for tool definitions without breaking legitimate server updates?
Sign in or go Pro to see the approach for this follow-up.
QHow does a rug pull differ from tool poisoning, and where do they overlap?
Sign in or go Pro to see the approach for this follow-up.
QWhy are remote MCP servers a sharper rug pull risk than local stdio servers?
Sign in or go Pro to see the approach for this follow-up.
QWhat would it take to solve this at the protocol layer rather than per host?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming OAuth or the initialize handshake stops rug pulls. They authenticate the server, not the integrity of each tool definition over time.