What Changed in the
MCP Trust Landscape
33 days of the version archive

There is a structural blind spot in how AI-skill and MCP-server trust is measured today. Every scanner I know of — including ours, until recently — answers one question: is this server safe right now? It fetches the repo, scores it, and discards what it saw. The next person to ask gets a fresh snapshot with no memory of the last one.

That model cannot, even in principle, catch the most dangerous class of supply-chain event, because those events are defined by change. A package you vetted last week is republished this week under the same version string with different bytes. A server you approved adds a tool you never saw. The maintainer account that published a trusted release is replaced overnight. A snapshot taken after the change looks exactly as trustworthy as one taken before — there's nothing to compare it to.

So in mid-May we started archiving every version of every server we score, and computing the diff between consecutive versions. This is the first report from that archive. The window is short — 33 days — and the point isn't the totals. It's the categories: the specific kinds of change that only exist if someone kept the previous state, and that every snapshot-based tool is blind to by construction.

TL;DR

Across 33 days (May 18 – June 20, 2026) the archive recorded 491 genuine version-over-version changes across 251 distinct servers, out of 1,044 tracked. The headline isn't the count — it's that 11 of those changes are install-time code execution or maintainer ownership events (the highest-severity supply-chain signals there are), and 108 are tools quietly added to servers people had already installed. None of these is visible to a tool that scores once.

The Signals a Snapshot Can't See

Here is the genuine-change breakdown for the window. I've grouped it by what the change actually tells you, not by raw frequency.

The 11 highest-severity events — one maintainer takeover, seven install-hook events, three same-version republishes — are the ones I want to walk through, because each is a textbook precursor to a supply-chain attack, and each is invisible without a previous state to diff against.

1. A Server's Entire Maintainer Set Was Replaced

I want to be precise about what this is and isn't. This is not a claim that the server was compromised, and I'm deliberately not naming the accounts — the point is the pattern, not any individual. A complete maintainer change can be a perfectly friendly handoff — a project changing hands, a company reorganizing a repo. But a complete maintainer change is also exactly what a takeover looks like, and it is the single signal you would most want flagged before you pull the next release. The honest answer to "was this benign?" is: you should look — and you can only know to look if something was watching the maintainer set across versions. A snapshot taken afterward shows one maintainer and no reason for concern.

2. Install Hooks That Appeared Overnight

An npm preinstall or postinstall script runs arbitrary code on your machine the moment you install a package — before you've imported a single line, run a single tool, or read any source. It is the most heavily abused vector in the entire software supply chain. The archive caught seven servers either adding an install hook that wasn't there before, or changing the command in one that was:

Read these the way the product does: as a strong prior, not a verdict. Most are plausibly benign — a tree-sitter build step, an Electron rebuild, a package-manager guard. But "plausibly benign" is a judgment you can only make if you know the hook appeared at all. Each one is new install-time code execution that a prior version did not have, and a one-time scan of the current version cannot tell you whether that postinstall shipped yesterday or has been there since day one. The diff can.

3. Same Version, Different Bytes

This is the subtlest one, and my favorite finding in the dataset. Three servers republished a shipped file under the same version number — the bytes changed, the version string didn't. The cleanest example is heshengtao/super-agent-party:

Whatever the intent — a botched release, a reverted experiment — the behavioral fact is stark: a user who ran npm install on June 12 got materially different code than one who installed the same version on June 11 or June 14. Lockfile pinning to a version number would not have protected them, because the version number never moved. spleck/claw-dashboard showed the same pattern on index.js on June 15. A scanner that hashed the package on any single day records one clean version and never knows it was a moving target. The archive sees the file change and change back.

4. Tools Added to Servers You Already Approved

When you approve an MCP server, you're approving a specific set of tools — a bounded capability surface your agent is allowed to invoke. 108 times in 33 days, a server on the tape gained a new tool. The approval you gave last week silently now covers capabilities that didn't exist when you gave it.

Most are mundane feature work, but the shape matters. adeze/raindrop-mcp added six tools in a single day — including bookmark_manage and tag_manage, write-and-delete operations on a user's data that weren't in the set you originally vetted. karanb192/reddit-mcp-buddy added user_analysis — "analyze a Reddit user's profile including karma, posting history, active subreddits." A read-only Reddit browser quietly became a people-profiler. None of this is malicious on its face. All of it expands what an already-trusted server can do to your data and your agent's context, and a snapshot taken today presents the enlarged tool set as if it were the one you signed off on.

What About Trust Scores Themselves?

The archive also recorded 146 trust-tier movements. I'm deliberately not leading with these, because honesty demands a caveat: a large share are transient. aquasecurity/trivy, for instance, dropped from Verified to Established on May 20 and recovered the next day — the kind of jitter you get when a single upstream signal (an OpenSSF Scorecard fetch, a rate-limited API) blips. Treating that as "trivy got less trustworthy" would be misleading.

But the phenomenon underneath is real and is itself the argument for the whole approach: a Verified score is a point-in-time reading, not a permanent property. Servers do durably cross from Established into Blocked within the window, and a one-time badge embedded in a README has no way to reflect that it's no longer true. Continuous diffing is the only thing that distinguishes a blip from a slide — and that distinction is exactly what a snapshot, by definition, cannot make.

What This Means for You

What This Data Doesn't Tell You

Methodology

The archive: every time the MCPSkills engine scores a server, it stores a structured version record — the manifest, install scripts, declared tools, maintainer set, shipped-file hashes, and the full trust score. When a server is re-scored, consecutive records are diffed and each detected change is written as a typed event (maintainer_flipped, install_script_added, binary_hash_changed, tool_added, tier_changed, and so on) with a severity. This report analyzes the complete diff store for May 18 – June 20, 2026: 5,547 raw records, of which 5,056 were endpoint first-observations (excluded as non-changes) and 491 were genuine version-over-version deltas across 251 servers.

Scoring: every server runs through the production mcpskills.io engine — the same 15-signal algorithm available at mcpskills.io. Full algorithm: /methodology. The live diff feed that backs this report is published at /feed/mcpskills-changes-v1.json and the full score dataset at /data/latest.json under CC BY 4.0.

Companion reports: The Trust Middle — State of MCP Server Security, State of Hermes Skill Security, and State of ClawHub Trust.

Data sources

Every diff in this report is reproducible from public data. The trust algorithm is an opinionated combination; the inputs are not.

• GitHub REST API — repository metadata, contributor/maintainer graph, release history, manifests, and file tree (for tool detection, install-script detection, and file hashing). docs.github.com/en/rest
• MCP Registry — registry.modelcontextprotocol.io, the official discovery source for tracked servers.
• npm registry — package manifests, version history, and install/preinstall/postinstall lifecycle scripts.
• OSV.dev + CISA KEV + FIRST.org EPSS — vulnerability and exploitation signals folded into each version's score. osv.dev