This server gives read-only MCP access to RugSnare’s public drift-feed and your local pin store.
Check public MCP server drift: drift_feed_status reports current versions and contract-change events from the public RugSnare drift-feed, covering popular MCP servers. You can optionally filter by server name (e.g. server-filesystem) or omit the filter to see all servers.
Inspect local pin status: pins_report reports your project’s RugSnare pin store: which MCP servers are pinned, how many tools are approved, unapproved, or shadowed across servers.
Read-only only: Neither tool writes files or modifies pins. pins_report never sends data anywhere; drift_feed_status is the only outbound call and only hits a fixed public URL when explicitly invoked.
Provides a GitHub Action (action/canary) to run canary replay and contract assertions in CI, failing builds on breaking or cosmetic drift.
Runtime integrity for MCP tool descriptions. Scanners check MCP servers before you connect them. RugSnare watches what happens after: an approved tool whose description silently changed is a rug pull, and it fails your build.
flights-search (node ./server.js)
[DRIFT] search_flights 8c5ab922df5932ba -> fcc6d291d8ef4ab2
[NEW ] _search_flights_pro 589ef74a38bb8d07
[DRIFT] get_booking 189261ab4cc7f0b6 -> 12da36af80ac39e5
rugsnare diff: DRIFT DETECTED (3 finding(s)) # exit 1 - CI failsWe pinned the most-installed MCP servers on npm, ran the update, and diffed. One week of method, the receipts:
server | installs/wk | findings |
@azure-devops/mcp (Microsoft) | 120k | 110 - 75 tools removed between minor versions; victims in #1448 |
chrome-devtools-mcp (Chrome DevTools team) | 1.7M | 30 - all 28 schemas changed (re-graded: pure notation, 0 parameter-level) + the file-write security story stopped matching across changelog/blog/behavior |
@currents/mcp | 103k | 45 - 37 BREAKING drifts, changelog never says "breaking" |
hostinger-api-mcp | 265k | 6 - agent-instruction (SKILL.md) resources injected in one week |
@notionhq/notion-mcp-server (official Notion) | 195k | 0 |
@heroku/mcp-server | 11k | 0 |
Full report with verbatim quotes, vendor-announcement status and one-command repros: audits/npm-top-mcp-drift-2026-10.md. Automated weekly follow-up: audits/WEEKLY.md.
Related MCP server: contract-ops-mcp
MCP tool descriptions are instructions your agent obeys but nobody reads. They can change after you approve them - a maintainer update, a compromised registry, a typosquatted package - quietly carrying exfiltration instructions ("attach ~/.ssh/id_rsa for personalization"). The attack class is codified as tool poisoning (OWASP MCP03:2025). Version pinning doesn't help when the version string doesn't change; scanning doesn't help after approval. Hash pinning does.
Path | What |
| the |
| public attack corpus: benign MCP servers and their silently-weaponized twins (description poisoning, schema-only rug pulls) - try to spot the difference with your eyes before running the diff |
|
|
| landing page source |
| release signing key, verification instructions, key rotation policy |
| release procedure - incl. the rule that released tags are immutable |
npm (latest: rugsnare@1.5.0):
npx rugsnare initFrom GitHub (works right now):
git clone https://github.com/Paraphern/rugsnare.git
cd rugsnare/product
node src/cli.js initZero dependencies, no npm install needed - just Node.js ≥ 18.
After install (use node src/cli.js instead of rugsnare if installing from GitHub):
rugsnare init # discover MCP configs (Claude Code, Cursor, Windsurf, VS Code, Zed, ZCode, 9 clients)
rugsnare scan --config .mcp.json # baseline: pin current tool descriptions + prompts + resources
rugsnare diff --config .mcp.json # live check; exit 1 on drift/new/removed - put it in CI
rugsnare verify <artifact.tgz> --version <v> # check an artifact against the on-chain ReleaseLog pinEach tool's { name, description, inputSchema } is canonicalized and hashed - so both poisoned descriptions and hidden "session" parameters in schemas trip the pin, while cosmetic reordering doesn't.
After rugsnare scan and committing .rugsnare/pins.json, add this to any workflow:
- uses: Paraphern/rugsnare/.github/actions/diff@v1That's it. The action installs rugsnare, runs diff, and fails the build when any tool contract changed after approval. Optional inputs:
- uses: Paraphern/rugsnare/.github/actions/diff@v1
with:
config: .mcp.json # path to your MCP config (default: .mcp.json)
version: '1.5.0' # pin the rugsnare version (default: 1.5.0)
schema-only: 'true' # fail only on BREAKING/EXPANDED (skip prose edits)
sarif: 'true' # also emit a SARIF report for code scanningBadge for your README:
[](https://rugsnare.com/#badge)The badge is a trust signal, not just a counter. Green signed · N tools · M skills ...
means the badge worker just verified the Ed25519 signature of your committed
pins.json against your committed pins.pub.pem (run rugsnare receipts sign to get
one). Yellow unsigned · ... means pinned but no signature; red SIG BROKEN · ...
means pins.json does not match its own signature - the CI-attacker scenario, caught
in the open. Gray is not pinned. Counts cover tools, skills, prompts and resources.
What the states mean →
rugsnare run --name flights --mode enforce -- npx -y @modelcontextprotocol/server-filesystem /tmpWraps a stdio server: observe watches and alerts, enforce additionally quarantines drifted/new tools mid-session. Measured overhead on the bench fixture (tools/bench-proxy.mjs, 200 round-trips): ~0.7–1 ms per tool call in observe mode, ~1.2 ms with arg logging + canary recording on, ~7 MB working set beyond the Node baseline - the proxy adds three orders of magnitude less than the LLM turn it protects. Idle CPU is zero (pure event loop, no polling). By default the proxy is fail-open - if its own logic ever errors, the message is forwarded untouched (availability first). Strict environments can flip it:
// .rugsnare/config.json
{ "failMode": "closed" }or per-run with --fail-closed - then a proxy internal error blocks the message and answers the client with a JSON-RPC error instead (integrity first, logged as proxy-fail-closed).
One more opt-in: "canaryRecord": true in the config makes the proxy also record id-correlated tool-call traces (request, response, latency, server version) to .rugsnare/canary/calls.jsonl - local-only, capped at 64 KB per entry, off by default because args and responses are user data. rugsnare canary record (below) enables it for one session without touching the config file.
Pinning answers "what changed?" The canary answers "can I upgrade?". While you work, the proxy records what your tools actually return; before an upgrade, replay that corpus against the new version and get a deterministic verdict:
rugsnare canary record --name flights -- npx -y flights-mcp@1.4.2 # work as usual; traces land in .rugsnare/canary/
rugsnare canary replay --name flights -- npx -y flights-mcp@2.0.0 # replay recorded calls against the NEW versionReplay diffs both the contract (split hash: BREAKING schema vs COSMETIC prose) and the behavior - a call that was ok and now errors, a response whose shape changed - while ignoring value-only differences (timestamps, prices change between runs), so no crying wolf. Replay is read-only by default: only read-like tool calls are re-executed; write-class and destructive-looking calls are skipped with a loud SKIPPED note (--include <tool> opts specific tools in, --all-calls lifts the write-class skip for sandboxes - destructive names always require explicit --include). Point replay at a dev instance, not production. Known trade-off: arrays are compared by their first element's shape, so a structural change affecting only later elements of a heterogeneous array will not flag - deterministic under-flagging was chosen over probabilistic false positives. Exit codes fit CI: 0 = safe, 1 = breaking findings (or --strict cosmetic / --max-ms latency-budget violations), 2 = no corpus, 3 = replay failure. Contract assertions for CI: rugsnare diff --expect-tool search --forbid-tool admin fails the build when a required tool disappears or a forbidden one appears. Traces are local and gitignored (rugsnare init writes that .gitignore for you); pins remain the only deliberate commit. Self-verifying demo: repro/canary.sh; CI integration: action/canary.
The proxy already logs every tool call. Receipts make that log provable: an Ed25519 hash-chain where each entry signs the hash of the previous one - edit, delete, or reorder anything after signing, and verify names the exact entry where the chain breaks.
rugsnare receipts sign # chain + sign the local event log (key generated locally, never leaves the machine)
rugsnare receipts verify # intact - or: BROKEN: entry #7 modified after signing (exit 1)
rugsnare receipts export # auditor dossier (markdown + JSON), fields aligned to IETF draft-sharif-agent-audit-trail-05Keys live in .rugsnare/keys/ (gitignored). verify --pub <pem> checks a receipt file against an exported public key - an auditor can confirm your trail without ever seeing a private key. One honest limit: the chain catches edits, insertions, deletions, and reordering inside it, but not a silent truncation of its tail (dropping the last N entries leaves a valid shorter chain). That is what the chain head printed by sign/export is for - anchor it somewhere the log writer cannot quietly rewrite (a commit, a message to the auditor) and compare. Also in v0.4: a loop detector - the proxy notices when the same tool is called repeatedly with identical arguments and no other tool in between (a stuck agent burning credits) and raises a one-time loop-suspected advisory; it never blocks anything.
The same binary doubles as a stdio MCP server, so agents can call it and marketplaces can list it:
{ "mcpServers": { "rugsnare": { "command": "npx", "args": ["-y", "rugsnare", "mcp"] } } }Two read-only tools: drift_feed_status (what the public drift-feed currently sees across popular MCP servers - the only outbound call this server ever makes, a fixed public URL, only when explicitly invoked) and pins_report (the local pin store of the project the agent works in - never writes, never sends anything). Pinned by our own gate, naturally - the baseline lives in corpus/03-rugsnare-self. A Docker image and registry entry are prepared under docker/ and registry/.
Every advisory hit and SARIF rule carries the ID of the ATR rule covering the same technique (e.g. a zero-width Unicode hit references ATR-2026-00129, contract drift references ATR-2026-00581, the post-approval rug-pull rule), so RugSnare pre-invocation findings and ATR runtime findings correlate in one pipeline. CLI output shows the IDs inline; --json returns them as an atr array; the SARIF export carries them in properties.atrRuleIds. Full table, plus three gap-proposals already filed upstream for review: docs/ATR-MAPPING.md.
Findings also speak OWASP's vocabulary: every RugSnare capability is mapped to the OWASP Top 10 for Agentic Applications risks it operationalizes (contract drift = ASI04 supply chain, shadow tools = ASI02 misuse, IDENTITY = ASI03, guard-parameter stripping = C9.2 irreversibility controls...), to the AI Testing Guide tests it serves as a tool for (AITG-INF-01 supply chain tampering above all), and to AISVS 0x10-C09 verification requirements - with gaps stated honestly. Full table: docs/OWASP-ASI-MAPPING.md.
We take our own medicine:
Zero dependencies - a supply-chain security tool must not be its own attack surface.
No telemetry. Local pin store, local JSONL event log, nothing leaves your machine.
Signed releases (Ed25519 OpenPGP, fingerprint in SECURITY.md, published in three independent places).
On-chain ReleaseLog - release hashes pinned append-only on Base mainnet (live since v1.0.0); rugsnare verify checks your install against a hash that has been in the ledger since release day.
Apache-2.0. If we ever go rogue - fork us. That's the license working as intended.
Ongoing research on how teams vet MCP servers: discussions/1 - 7 short questions, findings published. Author: @SergeyDruzhba on X.
How is this different from MCP Inspector / Glama Inspector? Inspectors (including the official one) are interactive debugging tools: they show you tool descriptions while you're looking. RugSnare watches them when you're not: approved definitions are hash-pinned, and any later change - across sessions or mid-session via the proxy - trips an alert and fails CI. Complementary tools: inspect before you approve, pin after.
Is this another MCP scanner? No. Scanners (snyk agent-scan, ex-mcp-scan) run at install time. RugSnare runs after approval, forever.
RugSnare pins the contract your agent obeys - { name, description, inputSchema } of every approved tool - and detects any silent change to it, between sessions (CI diff) and mid-session (live proxy). It does not inspect implementations.
Attack | RugSnare | The layer that owns it |
Tool description rewritten after approval (hidden instructions to the agent) | ✅ caught | - |
inputSchema mutated (hidden required | ✅ caught - see corpus 02 | - |
New tool appears / approved tool disappears post-approval | ✅ caught | - |
Cross-server tool shadowing (same name on two servers) | ✅ caught in | - |
Chameleon server (clean contract for inspection tools, poisoned for real clients) | ✅ caught by | - |
Behavioral hint flip ( | ✅ caught - annotations are pinned separately from the hash and compared through spec defaults (absent | - |
Mid-session swap of an already-connected server | ✅ quarantined in enforce mode | - |
Malicious code behind an unchanged contract | ❌ out of scope by design | package signing / provenance / sandboxing |
Toxic data inside call arguments or responses | ✅ caught (v0.3) - policies + PII egress checks in the live proxy | - |
Hijacked or destructive agent action (rm -rf class, download-pipe-shell, disk overwrite, fork bomb in call arguments) | ✅ denied by the default | - |
Compromised MCP client or host | ❌ | host security |
Attacker with write access to | ⚠️ trust boundary | commit pins to the repo and protect the branch - pins are only as trustworthy as the place you store them; signed pins are on the roadmap |
If an attacker changes the code but not the contract, no description hash can see it - that's a different layer's job. Defense in depth means layers; this tool owns the contract layer completely.
Incident | What happened | RugSnare | Source |
WhatsApp rug pull (Apr 2025) | Sleeper server: | ✅ caught - contract drift, | |
postmark-mcp (Sep 2025) | Republished under the same name; from v1.0.16 added | ❌ not caught - backdoor was in code, contract unchanged. This is package signing / SCA territory | |
Fake Oura Ring MCP / SmartLoader (Feb 2026) | Five fake GitHub accounts, three months of credibility, trojanized clone → StealC infostealer (passwords, seed phrases). Submitted to MCP registries | ❌ not caught - provenance attack, contracts identical to the original. This is signed releases / identity territory |
The silent changes report (repro/SILENT-CHANGES-REPORT.md): we pinned every stable release of the 4 official @modelcontextprotocol/server-* reference servers, diffed each version against the next, and counted every contract change between them.
Metric | Value |
Version pairs measured | 66 (complete coverage - every release of all four servers) |
Pairs with silent changes | 23 |
BREAKING (schema changed) | 43 |
ANNOTATION (behavioral hints flipped, spec-default aware) | 28 |
COSMETIC (description reworded) | 7 |
New items that appeared post-approval | 37 (24 tools, 5 prompts, 8 resources) |
Items removed post-approval | 24 (21 tools, 3 prompts) |
Clean pairs (precision, no crying wolf) | 43 |
140 findings. Not one was announced in a changelog. The most dramatic single step: filesystem 2025.8.21 → 2025.11.25 changed all 14 tool contracts simultaneously - 14 BREAKING schema changes in one silent release; everything's history is a churn machine: 31 items appeared (19 tools, 5 prompts, 7 resources) and 24 disappeared across its 27 releases. Reproduce on your machine: one command, ~30 minutes, deterministic - see the report footer.
Since v1.1.0 the same check exists for any npm package - rugsnare history <pkg> (or the Runtime scan in the browser) - and the results are public: e.g. @jadchene/mcp-ssh-service shows 359 silent changes across its 10 published versions, including a patch release that deleted "Requires confirmation" from 48 destructive tools (evidence: the runtime archive). Every capture records which schema-dep versions (zod, ajv, MCP SDKs) it was taken against - a floating zod: ^4.x range can rewrite a server's tool contract with no server release at all, and the scanner says so instead of letting dependency drift masquerade as server drift.
The public drift-feed watches hosted (remote HTTP) endpoints alongside npm packages - hosted servers change contracts with no release (the operator deploys server-side), which no npm pin can ever cover. Its coverage rule is stated honestly: a public feed cannot carry auth tokens, so only endpoints whose tools/list answers without authentication are monitored.
Version | Status | What's inside |
v0.1 | ✅ shipped | CI gate ( |
v0.2 | ✅ shipped | Live stdio proxy ( |
v0.3 | ✅ shipped | Call policies + PII egress checks - deny |
v0.3.1 | ✅ shipped | Split hash - BREAKING (schema) vs COSMETIC (prose) drift classification ( |
PR-diff Action | ✅ shipped | Human-readable tool-contract diff on pull requests. Demo: PR #2 · |
v0.4 | ✅ shipped | Canary - |
v0.5 | ✅ shipped | HTTP transport for |
v1.0.0 | ✅ shipped | Full stdio/HTTP parity: ad-hoc |
RugSnare as an MCP tool | ✅ shipped |
|
v1.0.1 | ✅ shipped | Fix release: Base Mainnet contract address as the default ( |
v1.1.0 | ✅ shipped | Skills Security: |
v1.2.0 | ✅ shipped | Drift gradation (P3-P6, four rounds from the KyttoMCP dialogue): BREAKING (tighten: new required params, narrowed types) - LOOSENED (constraints dropped, validation weakened) - EXPANDED (new optional param = attack surface widened) - NOTATION (dialect switch only) - guard-parameter warnings (dry_run/confirm/force removed, defanged, or default-flipped) - default value tracking (all params, previously invisible) - corpus/05 key-reorder fixture - |
v1.3.0 | ✅ shipped | Deep schema analysis: schemaDiff recurses into |
v1.4.0 | ✅ shipped | PIN-SPEC v1.1 (promised in autogen#7353 and snyk#482; spec text in docs/PIN-SPEC.md): identity block + identityHash per server, policyVersion stamp with the POLICY drift class (never silently re-grade under a new verifier policy - the ruler changes, not the vendor), IDENTITY drift class (tool hashes intact but the surface is served by a different build/path - supabase's entry move), byte-stable pins.json (sorted keys, unchanged entries never rewritten, savePins skips identical writes - third parties can JCS-hash the file as an opaque record) · paywall-introduction detection (R31: "requires a paid plan" is schema-silent - now a |
v1.4.1 | ✅ shipped | Skills pin |
v1.4.2 | ✅ shipped | §7 byte-stability for all pin branches: skills |
v1.4.3 | ✅ shipped | POLICY stop-rule (PIN-SPEC §3.1): when the pin store's policyVersion differs from the running binary, diff emits the POLICY finding and STOPS - exactly one finding, no tool-level classes follow. Each re-graded class would look like ordinary drift to anyone who scrolled past the POLICY line; the spec says "stops for that pin", and now the code does too · on-chain pin |
v1.5.0 | ✅ shipped | outputSchema pinning (R14: a third hash |
Later | 💭 | Hosted policy panel · Agent payment guardrails · resource/skill drift in history scans (see |
384 tests · CI on ubuntu+windows × Node 18/20/22 · CodeQL · field-tested on real packages · on-chain verified · zero dependencies · no telemetry.
Report the current versions and contract-change events of popular MCP servers, from the public RugSnare drift-feed (daily scans). Optional filter by server name.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Server name to filter by (e.g. server-filesystem). Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the source (public drift-feed) and freshness (daily scans), but says nothing about read-only semantics, rate limits, or the shape of the returned events beyond naming them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the filtering detail last. Every clause carries information; nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-style report tool with no output schema, the description names what is returned (versions and contract-change events) and the data provenance. The main gap is the absence of any safety/behavior note to compensate for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single optional parameter already fully documented in the schema. The description only restates the filter and its default (omit for all), adding no format or example detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Report) plus the resource (current versions and contract-change events of popular MCP servers) and even names the data source (RugSnare drift-feed, daily scans). It does not, however, differentiate itself from the sibling pins_report, so an agent must infer the split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is that the server filter is optional and omitting it returns all. There is no guidance on when to choose this over pins_report or what scenario each serves, leaving routing between the two siblings to guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the RugSnare pin store of this project: which MCP servers are pinned, how many tools are approved, unapproved, or shadowed across servers. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden, and it does declare 'Read-only', which is the key safety trait for a status tool. However it says nothing about cost, caching, auth requirements, or freshness of the reported counts, leaving gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence names the resource first, then the payload, then the read-only guarantee. No filler and nothing that fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only tool with no output schema, the description enumerates the returned information (pinned servers plus approved/unapproved/shadowed counts), which is enough for an agent to know what it will get back. Only the sibling relationship and any freshness/cost caveats are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and there is no parameter semantics to add. Baseline of 4 applies for a no-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (report) and a clearly scoped resource (the RugSnare pin store of this project), then enumerates the contents: pinned MCP servers and counts of approved/unapproved/shadowed tools. It is easy to distinguish from the sibling drift_feed_status by resource, though it never explicitly names or contrasts with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the alternative drift_feed_status or when a pin-store report is the right call. Usage is only implied by the read-only reporting nature of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.4.2drift_feed_statuspins_reportScored across 2 tools
The two tools have clearly distinct targets: drift_feed_status queries the public RugSnare drift-feed, while pins_report queries the local project's pin store. Their descriptions make the different data sources explicit, so an agent should not confuse them.
Both tool names use consistent snake_case and are noun-oriented read-only report names. However, the pattern is not a uniform verb_noun convention, and the mix of 'status' versus 'report' suffixes is a minor stylistic inconsistency.
Two tools is thin for a server named RugSnare that appears to cover MCP server drift monitoring and pin management. The count is not extreme, but it feels borderline for the likely domain.
Both tools are read-only reporting operations, leaving no way to pin/unpin servers, approve/unapprove tools, or otherwise manage the pin store. For a drift and pinning domain, these are significant gaps that would cause agents to hit dead ends for core lifecycle actions.
Security research: MCP registries verify identity, not tool behavior. See gtfo.dev.
Deterministic MCP, JSON Schema, and SemVer preflight via Agothe's public MUV scope.
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
