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.
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.
A rug pull attack on MCP is a timing attack on trust. The server presents a benign tool, the user approves it, and only later does the server return a definition that does something harmful under the same name. The term borrows from crypto scams, where a project looks legitimate until the operator drains it. In MCP the equivalent is a tool that is safe at install and malicious at some later moment of the attacker's choosing. The question is not whether such an attack is possible. It clearly is. The question is why the MCP specification itself offers no protection against it, and what that tells you about where the security boundary actually sits.
The short answer is that MCP standardizes how a host and a server talk, not whether a tool definition stays the same over time. There is no version field, no content hash, and no signature on a tool definition. The protocol therefore cannot tell a host that the tool it is about to call differs from the one the user originally approved. The trust model is implicitly trust on first use, and nothing re-checks that trust afterward.
This deep dive walks through what a tool definition actually contains, why the absence of integrity metadata is the root cause, why the obvious candidate defenses do not help, what a host has to build itself to close the gap, and where the ecosystem is heading. The recurring theme is that the protocol deliberately stops at discovery and transport, and pushes integrity up to the implementation, which is exactly where an interviewer wants you to locate the fix.
What a tool definition actually contains
When a host connects to an MCP server, it calls tools/list. The server returns an array of tool entries. Each entry has three meaningful parts: a name, a human-readable description, and an inputSchema expressed as JSON Schema. That is the whole contract. The host has no other channel through which to learn what a tool is.
The host shows the user some view of this, usually the name and description, and the user approves the server. From that point the host registers each tool as a function the model can call, mapping the model's function-call output back to a tools/call request on the server. The description is not just documentation for a human. The host feeds it into the model's context, so the model reads it as guidance on when and how to use the tool.
Notice what is missing from the entry. There is no version number. There is no content hash. There is no signature from a publisher key. There is no timestamp or revision counter. The description is free-form text the server controls, and the input schema can widen its accepted arguments without any flag. Nothing in the entry binds today's definition to the one the user saw at approval time. That missing binding is the entire vulnerability, and every defense in this answer exists to manufacture the binding the protocol left out.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| 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 products, models, and research that use this idea.
- Anthropic's MCP spec defines a tools list-changed notification for refetch, but leaves integrity checking and re-approval entirely to the host client.
- Invariant Labs demonstrated MCP tool poisoning and rug pull style attacks in 2025, hiding malicious instructions inside tool description metadata.
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?
Hash the canonical tool definition on first approval, store it keyed by server and tool name, and re-verify on every connect. On a diff, block and re-prompt with a side by side diff so the user can approve a legitimate update explicitly.
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.
Assuming OAuth or the initialize handshake stops rug pulls. They authenticate the server, not the integrity of each tool definition over time.
60 second bullets to scan on the way to the call.
Why a rug pull is a trust on first use problem
Which fields a tools list entry carries and which are missing
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.