You Approved an MCP Server. It Was Deprecated, Then Quietly Restored at a Version You Never Reviewed. That Happened Seven Times, and the Naps Are Getting Shorter.
You approved an MCP server. Somebody pulled it from the registry. Four days later it came back, at a version you never looked at, with a description you never read, and nothing in your pipeline said a word.
That is not hypothetical. It happened seven times in our snapshot series, and every single time the server returned at a different version than the one that went away.
What we can measure that almost nobody else can
We keep a dated snapshot series of the public Model Context Protocol registry. As of this morning it holds 7,196,928 rows across 42,455 derived findings and 126,272 dependency records. The value is not the size. The value is that it is longitudinal: we can ask what a registry entry looked like on a Tuesday in June and compare it to the same entry in August.
Most tooling cannot ask that question, because most tooling sees the registry the way you see a parking lot — whatever is there when you look. A snapshot series sees the empty space, and the car that came back into it.
Here is the full breakdown of what changed in that series, every finding type, no rounding: 22,516 version bumps, 19,365 new servers, 261 removals, 229 status flips, 53 findings from our own content hunter, 14 typosquats, 13 crawl anomalies, and three singletons. Of those 229 status flips, 222 went one direction — active to deprecated. Only seven went the other way.
Those seven are the interesting ones.
The naps
Five of the seven wake-ups had a matching deprecation inside our window, which means five measurable intervals. Five. I am going to keep saying that number because it is the honest limit of this finding.
Ordered by the date each server went dark, the intervals run 64 days, 21 days, then 1, 6 and 4. The two that went dark in June and early July averaged 42.5 days in the dark. The three that went dark on or after July 26 averaged 3.7 days.
That is an order-of-magnitude difference between the early cluster and the recent one, and I want to be precise about what it is not. It is not a smooth collapse. A one-day nap is followed by a six-day nap and then a four-day nap, so the line wobbles. It is two clusters with a gap between them, drawn from five data points, and five data points can be a coincidence wearing a lab coat.
For scale: the GitHub account we wrote about on July 9 stayed dormant roughly 578 days before it woke up to drop an exploit kit. Nine times the longest bar on that chart. If the short naps are real, the behavior has changed shape entirely, from a long-con sleeper to something closer to a blink.
Why a one-day nap is invisible
If you check your dependencies weekly, a server can be deprecated on Sunday and restored on Monday and you will never see the gap. Your scan on the following Sunday shows an active server with a slightly higher version number, which looks exactly like ordinary maintenance, because it is indistinguishable from ordinary maintenance at that sampling rate.
This is the part that should bother you more than the dormancy itself. The detection depends entirely on how often you look, and almost nobody looks daily at registry metadata. We only caught these because we snapshot the whole registry every day and keep the old snapshots, which is a strange thing to do and is the only reason there is anything to write.
The finding that matters more than the dormancy
Seven wake-ups. Seven version changes. Not one server came back at the version it was pulled at.
One returned having advanced 177 patch versions. One went from 0.9.3 straight to 1.0.0. One went from a calendar version in April to a calendar version in July. And five of the seven also changed their description text — the human-readable blurb that an AI agent reads when it is deciding whether this tool is the right one to call.
So the review you performed was of an artifact that no longer exists. You approved version 1.0.0 and you are now running 1.1.1, and the transition between them was not a normal upgrade you could have reviewed in a changelog diff; it was a disappearance and a reappearance. Point-in-time vetting of a mutating object is not a control. It is a photograph of a thing that has since moved.
To be fair to the publishers involved: deprecating and restoring a server is a completely legitimate thing to do. People yank a release because it broke, fix it, and put it back. Nothing in this data proves anyone did anything wrong, and I am not alleging that any of the five named servers is malicious. The point is structural. The registry permits a state transition that your tooling does not model, and that gap exists whether the publisher is careless, busy, or hostile.
The siblings share a grammar
Separately in the same index sit 14 typosquat findings, all flagged as the SmartLoader family. We did not find these. URLhaus, run by abuse.ch, tagged the repositories as serving SmartLoader, and our tooling seeded them as known positives on May 4. The detection credit is entirely theirs, and if you take one operational thing from this paragraph, take their feed rather than ours.
What is ours is the observation about the names. Read them together: mail-mcp-bridge, mcp-agent-bridge, context-bridge-mcp, whatsapp-bridge-mcp, mcp-accessibility-bridge, mcp-bsl-lsp-bridge, cheatengine-mcp-bridge. Then mcpshim, acemcp, pocketmcp, sitecoremcp, codex-mcp-go, agentic-mcp-skill, mcp-claude-hackernews.
Fourteen different account names, one naming convention: a real-sounding product word welded to "mcp" and usually "bridge." This is the same shape we keep finding in infrastructure, where a feed lists the one burned host and the numbered siblings stay live. The lesson transfers directly to package registries. When you burn one of these, do not search for that name. Search for the grammar.
What our own detector got wrong, today
There is a fourth finding type in that index, and it is the reason this section exists: 53 high-severity hits called direct-skill-payload, all on a single repository, all triggered by the same pattern inside a README file.
That looked like a great story. A payload hiding in the one file every supply-chain scanner skips and every agent reads is exactly the kind of mechanism that ruins your week. So we opened them.
The pattern our hunter matched was a node one-liner of the shape node -e "console.log(require... which is how approximately every JavaScript project on earth documents a version check. It is documentation. Fifty-three high-severity findings, one repository, one benign line, and had we published it, we would have named an innocent maintainer as a malware host.
That is the third false positive of this exact class we have caught in our own feed in a single day. Earlier we found two URLs from somebody else's detection-test corpus sitting in our published blocklist, and a security researcher's own git server typed as a malicious domain since June. All three were downgraded, with the records kept as receipts rather than deleted.
The general lesson is not that our detector is bad. It is that a detector with no denominator will hand you 53 confident findings that are one finding, and the number 53 will feel like evidence. Open the findings. Read the matched string. The count is not the finding.
What would prove this wrong
The dormancy claim rests on five intervals, so here is the test, written down in advance: if the next twenty wake-ups we record average longer than these five, the shortening is noise and we will publish that with the same prominence as this. If they average shorter, the behavior is real and the sampling-rate problem becomes urgent for everyone, not just us.
We will know in a few months. The series keeps running either way, which is the only part of this that is genuinely defensible: the measurement continues whether or not it flatters the hypothesis.
What to do about it on Monday
Pin MCP servers by version and digest, not by name, so a restore-at-a-new-version cannot silently satisfy your dependency. Re-check registry status on a daily cadence rather than weekly, because the shortest nap we measured was one day and a weekly cadence cannot see it. Diff the description text as well as the code, because the description is the part the agent reads before deciding to call the tool. And when you find one bad package name, hunt the naming grammar rather than the name.
None of that requires our feed. It requires treating a registry entry as a live object rather than a fact you checked once.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=you-approved-an-mcp-server-it-was-deprecated-then-quietly-restored-at-a-version-you-never-reviewed
Comments