When you approve an MCP server, what happens at its next version?
We launched here last Monday. One number from our prep keeps coming up in conversations, so a question.
We ran every stable version of 14 of the top 30 npm MCP servers from March to September in a throwaway environment, tools/list only. 86 version-to-version transitions. 40 of them changed what the tools do or accept, 47%. The largest category was not added tools. It was rewritten parameter descriptions, 92 of them. The agent reads that text and acts on it. The person approved the server once and never reads it again.
mcpgawk sits on that gap: baseline at approval, refuse the call when the surface changes until a human looks. https://mcp.gawk.dev/ph if you want to try it.
So: when you add an MCP server to Claude Code, Cursor or Codex, what do you do at its next version? Pin it, re-read the tools, or trust the update?
Replies
How do you handle a server update that changes behavior but leaves tools/list unchanged?
I would want the approved baseline tied to the package version or build too. Otherwise the same tool description could still be backed by different code
@al_kub Honestly.. it doesn't today. We hash what the server declares not the code behind it.. so same text with different behaviour gets through.
Closest we have is .. approve --fleet hashes the launch line.. so a version bump in your config shows up as a new entry to approve and verify runs the server in a sandbox and stops a sink being called after a source. You're right that it should be tied to the build. For now, pin the version in the config.
Yeah been there. I've had agents trust a tool description that quietly drifted, so I keep a baseline and a review point before updating it. Do you flag changes that look harmless in the schema?
@matheus_paranhos1 Yes. scan shows every change .. down to a one word edit. It only blocks the call for some of them.. the tool's description changed, a new tool, permissions grew or a change that got reverted before anyone saw it. A type change or a rewritten parameter description goes in the queue and the call still runs.
Didn't want to break things that were working. What does your review point look at?
Great data. Rewritten tool descriptions are basically silent prompt changes, so they're a quiet source of specification drift. I pin versions and diff the tool schemas and descriptions in CI before upgrading. Would love to see you hash the descriptions too, since those are what the agent actually reads.