Before you read on, open your MCP config. Look at how each server gets installed. If a line says @latest or has no version at all, that server can change under you the next time it starts.
Mine had plenty of those. That's how this whole thing started.
A couple of weeks ago I posted that 49 of 107 updates to popular MCP servers changed what their tools tell your agent. I half expected someone to tell me I'd got it wrong. Instead a writer at Decoding AI counted nine of the servers herself and got 48%. When I reran her nine the same way, eight came out with exactly her numbers. That was a relief.
Most of the other replies asked the same thing in different words. Fine, they change. Which of those changes should actually worry me?
I didn't have a good answer. So I went back to the same data and sorted every one of the 49.
The question I asked of each update
Can the tool now do something it couldn't do when you approved it?
I said yes if the update did any of these:
- added a new tool
- rewrote what a tool's description tells the agent to do
- added a parameter that points somewhere, like a URL, a file path or extra HTTP headers
- dropped a safety label or added one that says the tool reaches the open web or can destroy things
Anything else I called a reshuffle. A renamed parameter, a tightened type, a reworded sentence inside a parameter, a removed tool.
What came out
| updates | |
|---|---|
| Changed the tool surface | 49 of 107 |
| Could now do something new | 25 |
| ...new tool | 7 |
| ...tool description rewritten | 12 (one of them only whitespace) |
| ...new parameter that points somewhere or a safety label change | 6 |
| Reshuffle only | 24 |
About half the changes were nothing. The other half were the kind I'd want to look at before my agent used them.
What bothers me is that you can't tell the two apart from the outside. Both arrive as the same package with a small version bump. The release note usually doesn't mention the tool text at all.
Three I keep thinking about
Playwright. Between 0.0.71 and 0.0.72 the tool browser_run_code disappeared and browser_run_code_unsafe turned up with the same inputs. The old description said it runs a Playwright code snippet. The new one says it executes arbitrary JavaScript in the server process and calls that RCE-equivalent.
I actually like this one. The maintainers were honest about what the tool does. But think about an agent that approved the first version. It's now calling the second and nobody asked you.
Chrome DevTools. In 1.1.0 the emulate tool gained extraHttpHeaders. The parameter's own example is an Authorization: Bearer header added to every request. Only four updates in the whole set added a parameter that points somewhere. Three of them are this one server.
Filesystem. In the official filesystem server, read_media_file used to say it reads an image or audio file. A July release changed that to say any other file type comes back too. The inputs didn't change at all. Only the sentence did.
That last one is the one I'd show a sceptical colleague. The sentence is the part your agent reads.
Not every flag is an attack
Two of the six label changes were servers describing themselves more honestly. MongoDB's server added the "reaches the open web" label to every tool in 2.0.0. CircleCI's went from no labels at all to marking eight tools as destructive.
I'd still want to see those, since they change how an agent should treat the tool. They just aren't a rug pull. I don't want to call a careful maintainer an attacker.
OWASP's MCP cheat sheet was updated last week along the same lines. It says to hash the whole tool definition with the labels in it. A flipped label can change what a client allows while the description looks the same.
What I'd do with this
Pinning every server version handles all 49. It also means you never get the fixes. Reading every release note isn't realistic either. The notes mostly skip the tool text anyway.
What seems to work is splitting it the way the numbers split. Stop on the 25 that let a tool do more, until someone has looked. Let the 24 reshuffles through and look at them when you get round to it.
That's what I've been building mcpgawk to do. It keeps the tool text you approved and holds the call when an update lands in the first group. I made a 50 second film of what that looks like on an ordinary morning:
Where this falls short
- I launched every version without API keys. Some servers show more tools with a key. Eight wouldn't start without one and aren't in this at all.
- The "points somewhere" check goes by parameter names. It would miss a widening that only shows up in prose, like the filesystem one. That one gets caught because the description changed, not because of the parameter.
- 30 packages, March to September 2026. It's one slice, not the whole ecosystem.
The data and the script are on GitHub if you want to rerun it or argue with how I sorted things: https://github.com/gawk-dev/mcpgawk/tree/main/research/tool-churn-2026
I'd really like to know what you do today. When an MCP server updates, do you take it blind, pin it or do something in between? And if you went and looked at your config at the top of this post, how many @latest lines did you find?
Top comments (1)
You should stop your agent on the 25 updates that allow a tool to do something new, while letting the 24 "reshuffled" updates pass through.