Build1 publisher3 min readPublished
Live MCP servers trail the stateless 2026-07-28 revision that clients already ship
Pennyforge found 7 of 72 responding MCP registry endpoints on the stateless 2026-07-28 revision that clients already ship. Servers answer with whatever in-range version a client offers, so a client learns what one supports only by offering the newest revision and reading the reply.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- All five of the ten prominent npm MCP servers that answered spoke only the 2025-06-18 revision and rejected the new server/discover call.
- A follow-up probe calling server/discover found 8 of 109 answering endpoints, across the two cohorts Pennyforge combined, accepting the new-revision call.
- Forty-three servers that looked like 2025-11-25 or 2026-07-28 speakers on October 1 all echoed back 2025-06-18 when offered it on October 2.
- Three of the seven endpoints answering on the new wire belong to a single operator.
- The 186 probed endpoints are a contiguous slice of hostnames starting with a or b from the registry's first 900 listings, not a random sample.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A client that speaks only 2026-07-28 would reach a small minority of the endpoints measured, so dropping the legacy initialize path is premature for anyone who needs today's servers.
- cost Supporting both eras puts two code paths in one client: initialize and session headers for older servers, per-request _meta and server/discover for newer ones.
- exposure Monitoring and registry tools built for one revision's layout will undercount live servers without raising an error, as the x402 parser that missed 87 payTo fields did.
The 2026-07-28 revision moves version negotiation out of a handshake and into every request. Clients put protocolVersion and their capabilities in _meta on each call [2]. The initialize handshake is deleted, Streamable HTTP drops the Mcp-Session-Id header, and a server/discover RPC replaces session discovery [1]. Older servers still expect initialize first, and Pennyforge's probes treat it as the legacy handshake [8]. By Pennyforge's count the server side is five populations, one per spec revision, most of them "invisible to each other without an error" [16].
The October 2 floor test explains what the first census had counted. Offered a version above their maximum, these servers answer with the maximum [11]. Four were checked that day. The api.aislabs.ai and bankrolled.ai endpoints accepted every version from 2024-11-05 to 2026-07-28. The mcp.getle.ad endpoint had a floor of 2025-03-26. The advisorsai.ai endpoint answered a 2026-07-28 offer with 2025-11-25 [12].
Pennyforge's decoding rule follows from that [13]. An echo of the offered version means the server speaks it. A lower version means it caps below the offer. An UnsupportedProtocolVersionError means its floor sits above the offer [13]. The first probe sent a POST initialize offering 2026-07-28 with a browser User-Agent and classified each reply by negotiated version and session header [4]. Six of the seven new-wire endpoints were negotiating, and one was pinned [5].
The local npm servers fail loudly. They reject server/discover outright, so the client at least sees the mismatch [8]. Five of the ten gave no answer to either probe [1]. The reference @modelcontextprotocol/server package is no help as a yardstick, since npm cannot find anything in it to run: "could not determine executable to run" [9].
The quiet failures sit in the readers. A reader hard-coded to one era "sees half the population as missing," Pennyforge writes, and "nothing errors" [14]. It reports the same pattern in x402 this week. Version 1 carried payment requirements in the 402 body. Version 2 moved them, base64-encoded, into a PAYMENT-REQUIRED header, and one operator's body-only parser marked 87 of 183 "doors" as having no payTo when all 87 had one [15].
In my view a client should try server/discover first, fall back to initialize offering 2026-07-28 when that call is rejected, and store the returned version per server. Pennyforge says major clients already ship the new revision [10]. The write-up does not say which clients, or whether they keep a fallback.
The probe numbers transfer only if two things hold. Hostnames starting with a or b would have to resemble the rest of the registry. Registry listings would have to resemble what is actually deployed. The slice is also thinner than its 186 entries suggest: 114 endpoints returned no protocol version at all [3], and the seven new-wire endpoints come from at most five operators [2]. A re-probe 39 minutes later returned the same class shape [6]. The study cost $0 and used only the public registry and public endpoints [17].
What to watch
- Whether the @modelcontextprotocol/server reference package ships a default executable and a 2026-07-28 implementation.
- A rerun of the probe beyond hostnames starting with a or b, to test whether the 9.7% new-wire share holds across the registry.
- Which major clients ship 2026-07-28, and whether they fall back to initialize when server/discover is rejected.