What is an MCP rug pull attack?

Tool poisoning is malicious from the moment it's installed — the harmful instruction is already in the description a user never fully reads. A rug pull is a timing attack: the tool is genuinely safe when it's reviewed, and only becomes unsafe afterward, once the maintainer (or an attacker who's compromised the maintainer's account or CI pipeline) pushes an update that most clients never re-review.

The term borrows from crypto and DeFi, where a project builds trust and liquidity before the operators withdraw funds and disappear. The MCP version is the same shape: build trust through a benign initial version, then exploit the permissions already granted once nobody's watching closely.

Many MCP repositories don't maintain strict semantic versioning, and even when they do, a maintainer can change a tool's actual behavior without bumping the version at all — a rug pull is defined by a change in behavior, not necessarily a change in the number attached to a release.

This is precisely why relying on 'last release date' or version comparisons as a freshness signal is insufficient on its own for catching this specific attack — the code can change between releases, or the description/behavior can shift in ways a version bump doesn't reflect.

This is what tool-definition content hashing exists for: aimcplist hashes each tool's name and description, and re-checks that hash on every sync — independent of whether a version number changed. (Parameter hashing is a tracked follow-up, not yet part of the hashed content — a rug pull that changes what a tool does typically changes its description too, which the current hash already catches.) A hash mismatch is treated as a real change requiring fresh review, and for the human-reviewed top tier, either that hash changing or a major version bump automatically strips the Human-Verified badge and re-queues the server for review. A stale human review is treated as worse than no review at all, specifically because of this attack pattern.