I re-ran 152 versions of popular MCP servers. Nearly half the updates changed what the tools tell your agent.

mcpgawk is live on Product Hunt — see the launch and leave your take

You approve an MCP server once. Your agent trusts it from then on.

But the server is an npm package, and most install lines are unpinned. The next launch after a release runs the new version. Nobody asks you again.

So I wanted to know a boring, measurable thing: how often does an update actually change what the tools say?

What I did

I took the 30 most-downloaded MCP server packages on npm. For each one I pulled every stable version published between March and September 2026 (up to 12 per package), and launched each version the same way:

• npx -y <package>@<version> in a throwaway home directory
• no API keys in the environment
• initialize + tools/list only — never a tool call

Then I stored each version's tool surface (name, description, input schema, annotations) and diffed every version against the one before it.

The numbers

An independent researcher, using her own setup on nine servers, measured 48% across 96 releases. Two methods, two machines, the same answer: roughly every second update changes what your agent is told.

What actually changes

I expected new tools. That's not where the churn lives.

• Tools added / removed: 12 / 4
• Updates with an input-schema change: 33
• Parameter descriptions rewritten: 92 — the biggest category by far
• Parameter types changed: 5 — the rarest

One package kept the same two tools for six months, while their descriptions and schemas moved three times. If you only diff tool names, you see nothing.

That matters because the description is the part your model reads and obeys. A rewritten parameter description is a new instruction, delivered silently.

Why "approve once" breaks

Every MCP client I've used asks for consent on the first connect. None of them asks again when the server changes underneath you.

A real one from my own machine: one server changed its tool list 6 times in 6 releases, from 85 tools to 103. New ones included update-api-key and share-email. My agent would have called every one of them without a second look.

Most of these changes are honest product work. That's the point — you can't tell the honest ones from the hostile one by waiting for a CVE. You can only tell that something changed since you said yes.

What I'd do about it, with or without my tool

1. Pin versions in your MCP config. @latest and bare npx -y mean the next launch runs whatever was published last.
2. Snapshot the tool list when you approve a server, and diff it on every launch. Even a JSON dump and git diff beats nothing.
3. Diff descriptions and schemas, not just names. That's where 9 out of 10 changes live.
4. Probe without your keys when comparing. One server exposed extra tools only when a key was present — an easy way to fool yourself.

The thing I built

I got tired of doing step 2 by hand, so I built mcpgawk: it records what every tool said when you approved it, and if a tool rewrites its description or gains power afterwards, the call is refused before it runs — until you decide. The agent can't approve its own way past it. It runs locally; nothing is uploaded.

uv tool install mcpgawk && mcpgawk

It's live on Product Hunt now, and I'm using the thread there as the place to collect one answer I don't have yet:

How do you find out today when an MCP server you already approved changes?

If you've got an answer — a script, a habit, "I don't" — I'd genuinely like it in that thread: mcpgawk on Product Hunt

Method caveats, stated up front: probing without keys understates servers that gate tools behind a key, and excludes six that won't start without one. "Changed the tool surface" means any change to name, description, input schema or annotations; one update counts once however many tools moved. Ask in the comments and I'll share the per-update list.