Only 1% of MCP servers speak the current spec
We measured 19,233 public MCP servers. 198 of them negotiate the current protocol revision. Here is what that gap means if you build clients or servers.
Every MCP server announces which protocol revision it speaks during the initialize handshake. That makes adoption measurable, so we measured it across the whole public ecosystem.
The numbers
Out of 19,233 servers we probe continuously, 198 negotiate the current revision. That is 1.0%. Another 1,451 — 7.5% — land somewhere in between: they recognise the modern framing but settle on an older revision. Everything else is still on the previous generation.
The gap is not a rounding error. It is the ecosystem.
Why adoption is this slow
- The SDKs lag. Most servers are a thin wrapper around an official SDK, and the SDK pins the revision. Until that version bumps, the server cannot move even if the author wants to.
- Nothing forces the upgrade. Clients stay backward compatible, so an old server keeps working. There is no error message, no deprecation warning, no user complaint.
- Most servers are unattended. A weekend project does not get a protocol upgrade six months later.
What it means if you build a client
Do not assume the current revision. If your client only offers the newest version during negotiation, you will fail against 99% of the ecosystem. Offer the newest, accept what comes back, and handle the older shape.
What it means if you build a server
Upgrading is one of the cheapest ways to stand out right now, precisely because so few have. But check one thing first: the protocol version header belongs on requests after the handshake, not on the handshake itself. Sending it during initialize makes some servers reject clients outright — we found servers that were unreachable for exactly this reason.
See which servers are on which revision