mcpgawk

Advisory · 1 August 2026

Two of the three official MCP servers we tested stopped starting.

The Python MCP SDK released v2 and renamed McpError to MCPError. A server breaks only if it does BOTH: leaves the SDK unpinned, and imports something v2 renamed. That is not everyone — but it is not rare either, and when it happens your agent just reports the server as unavailable.

What we actually tested, on 1 August 2026, with uvx on a clean cache: mcp-server-time fails · mcp-server-fetch fails · mcp-server-git starts fine. All three declare the same unbounded pin (mcp>=1.x), so the pin alone does not decide it — importing a renamed symbol does. Node/TypeScript servers are unaffected: the npm SDK is still 1.x.

What it looks like

A server that ran last week, launched today:

ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'.
Did you mean: 'MCPError'?

That text is on the server's stderr, which nothing shows you. Your agent reports a failed connection. The config is correct. The maintainer's code is correct — for the SDK it was written against.

Who this hits. Python servers that resolve the SDK fresh at launch (uvx, pipx, an unlocked pip install) AND use one of the renamed APIs. A server already installed keeps working until something reinstalls it — your next container rebuild, a new laptop, a CI runner with a cold cache.

Check yours, in one command

Any install-on-launch server (uvx, npx) is a candidate, because it resolves dependencies fresh every time. Run one and watch its stderr:

uvx mcp-server-time 2>&1 | head

If you see the ImportError above, that server is already broken on a clean machine — your teammate's, your CI runner's, any container you rebuild. If it starts normally, that one is fine; mcp-server-git was, on the same day, with the same kind of pin.

Why a review wouldn't have caught it

Nothing in the server's manifest, README or tool descriptions says this. It isn't a code-review finding or a config mistake. It only exists at the moment the thing actually runs, which is why we found it by running servers rather than reading them.

That is the whole difference between describing software and observing it. mcpgawk verify launches each server in a sandbox, watches what it does, and reports the real failure instead of "connection closed".

What to do now

If you maintain a Python MCP server: cap the SDK (mcp>=1,<2) or migrate. McpError→MCPError is one of several renames we hit porting our own code: isError→is_error, inputSchema→input_schema, mcp.server.fastmcp→mcp.server.mcpserver.

If you run MCP servers: find out before your next rebuild does. The scanner is free and runs locally; nothing leaves your machine.

uv tool install --force mcpgawk && mcpgawk
Honest scope: the free scanner inventories every server your agents can reach and measures what each exposes. Running each server in a sandbox to reproduce failures like this one is the paid pillar. We would rather tell you that plainly than let you find out after installing.