Skip to content

Back to the catalog

The MCP Ecosystem Is Speaking Five Revisions at Once
dev.towriteup

The MCP Ecosystem Is Speaking Five Revisions at Once

A dated research report (Pennyforge, 2026-10-02) that probes the live MCP ecosystem to show it is fragmented across five spec revisions at once: it POSTs initialize/server/discover calls against 186 deduplicated endpoints pulled from the official MCP registry's v0 API, plus 10 popular npm stdio servers spawned via npx. It finds only ~9.7% of responding endpoints speak the new stateless 2026-07-28 wire (which removes Mcp-Session-Id, the initialize handshake, and adds server/discover), that the flagship @modelcontextprotocol/server npm packages still only speak the older 2025-06-18 revision, and documents a "version-echo" methodology pitfall where servers negotiate within a supported range rather than reporting a fixed version — illustrated with a parallel failure mode found in the x402 payment protocol.

TL;DR An independent wire-level census finds the live MCP server ecosystem splintered across five spec revisions, with under 10% of endpoints yet speaking the new stateless 2026-07-28 protocol.
Document

What it claims

On a 186-endpoint slice of the official MCP registry, only 7 of 72 endpoints that returned any protocol version (9.7%) negotiated the stateless 2026-07-28 revision. Those 7 are not independent adopters: three are paths on one operator (api.aislabs.ai/{,cve/,recorder/}mcp). A separate test of whether servers accept the new server/discover call found 8 of 109 answering endpoints (7.3%) across both cohorts. Five of ten prominent npm stdio servers answered, and all five speak only 2025-06-18 and reject server/discover. The reference @modelcontextprotocol/server package fails under npx with could not determine executable to run.

How it works

The 2026-07-28 changes the probes target, from the spec changelog:

  • initialize and notifications/initialized are removed. Clients instead send protocolVersion and capabilities per request in _meta.
  • server/discover is new.
  • subscriptions/listen replaces HTTP GET plus resources/subscribe.
  • ping, logging/setLevel and roots/list_changed are removed.
  • Server-initiated requests are replaced by MRTR (multi-request/multi-response).
  • Tasks move to the io.modelcontextprotocol/tasks extension.
  • Error codes −32020 to −32099 are reserved.

The three probes:

  1. Remote, 10-01. POST initialize offering 2026-07-28 with a browser User-Agent. Each endpoint is classified by the version it negotiates back and by the session header. The same cohort was re-probed 39 minutes later and produced the identical class shape.
  2. Stdio. Ten servers spawned with npx -y, each sent initialize and then server/discover.
  3. Remote, 10-02. initialize requesting the floor version (2025-06-18), then server/discover. The 3 acceptors were mcp.getle.ad, analyticslegends.ai and api.askmiles.ai.

Comparing the two remote probes showed that 6 of the 7 new-wire endpoints were negotiating, and only 1 was pinned.

The version-echo pitfall

On 10-01, 43 servers appeared to "speak" 2025-11-25 or 2026-07-28. On 10-02, when offered the floor version, all 43 echoed the floor back. Servers echo any version within their supported range and report their maximum when the request is above it. The page verified this on four servers:

  • api.aislabs.ai and bankrolled.ai accept everything from 2024-11-05 to 2026-07-28.
  • mcp.getle.ad has a floor of 2025-03-26.
  • advisorsai.ai caps at 2025-11-25.

The rule that follows: to test capability, request the highest version you care about and read the answer.

flowchart TD
  A[Request highest version you need] --> B{Response}
  B -->|Same version echoed| C[Speaks it]
  B -->|Lower version| D[Capped below]
  B -->|UnsupportedProtocolVersionError| E[Floor above you]

A client hard-coded to one revision silently sees part of the population as missing; nothing errors. The page cites the same failure shape in x402. In v1 the payment requirements are in the 402 body; in v2 they are base64 in a PAYMENT-REQUIRED header. One operator's body-only parser marked 87 of 183 endpoints "no payTo" when all 87 had one.

How to use it

The method scripts are mcp_census.py and probe-remote.py. They are kept alongside the per-URL classes and dated probe notes, linked from the page. All data comes from the public registry and public endpoints, at $0. The next re-probe of the cohort is scheduled for 2026-10-08. It will request 2026-07-28 and classify each answer as echo, cap or error.

Limits

  • Not a random sample. The cohort is a slice by hostname (a–b) from the first 900 registry listings in default order.
  • Auth-gated half unseen. About 47% of the cohort is auth-gated, so the numbers describe only the public half.
  • Discover acceptors may be older servers. The project blog and the spec disagree on whether server/discover is optional, so the 3 acceptors may actually be 2025-11-25 servers.
  • Pinned is not the same as old. A server pinned to 2025-11-25 may still accept 2026 clients.
  • Dates are inconsistent. The page calls the probes "one week apart" and "a direction, not a trend," but its timestamps are 2026-10-01 05:27Z and 2026-10-02 00:45Z, less than a day apart.

Organisations named here

Technologies named here

Techniques named here

  • Stateless rewrite
  • server/discover RPC
  • subscriptions/listen
  • MRTR
  • Version-echo negotiation