mcpcensus

What changed in MCP 2026-07-28

learn · updated 2026-07-31 · methodology · lookup

The Model Context Protocol's 2026-07-28 revision is the largest change since the protocol launched. If you run an MCP server, two of its changes decide whether existing clients can still talk to you.

The handshake is gone

Before this revision, a client opened a session with an initialize call and the two sides negotiated a protocol version once. That is removed. MCP is now stateless: every request carries its own version and client capabilities in _meta:

``json "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" }, "io.modelcontextprotocol/clientCapabilities": {} } ``

Protocol-level sessions and the Mcp-Session-Id header are gone with it. State that used to live in a session now travels as explicit, server-minted handles passed as ordinary tool arguments. This is what makes the protocol deployable on serverless and edge infrastructure without sticky routing.

server/discover is mandatory

Servers must implement server/discover. One call returns the revisions a server supports, its capabilities, and its identity:

``json { "resultType": "complete", "supportedVersions": ["2026-07-28"], "capabilities": { "tools": {} }, "instructions": "…" } ``

A client no longer probes tools/list, prompts/list and resources/list separately just to learn what a server can do.

What else moved

  • Extensions are versioned and official. MCP Apps (interactive UI in a conversation) and Tasks (long-running work) now ship as extensions, advertised in a capability map, without changing the core protocol.
  • Server-initiated requests are replaced by MRTR. Instead of the server sending its own request for sampling, elicitation or roots, it returns an InputRequiredResult and the client retries the original request with the answers attached.
  • ping, logging/setLevel and SSE resumability are removed. A broken response stream loses the in-flight request; the client re-issues it.
  • Authorization hardened. RFC 9207 iss validation, Client ID Metadata Documents in place of Dynamic Client Registration, and enterprise identity systems without workarounds.
  • Roots, Sampling and Logging are deprecated under a new lifecycle policy with a minimum twelve-month removal window. They still work. New implementations should not adopt them.

What this means if you run a server

Nothing breaks on day one. The spec explicitly allows a server to serve both eras from one endpoint: answer server/discover and per-request _meta for new clients, keep initialize for everyone else. Every widely deployed client today is still handshake-era, so dropping initialize now would disconnect your existing users.

Three practical notes:

  1. Streamable HTTP POSTs now require Mcp-Method and MCP-Protocol-Version headers, and their values must match the request body. A mismatch is a 400 with error -32020.
  2. An unsupported version is -32022, and the error must list the versions you do support. That list is how a well-built client recovers instead of giving up.
  3. Sessions and the new revision are incompatible by design. If your framework has sessions enabled, it cannot serve 2026-07-28 requests even if the SDK recognises them.

How to tell what a server actually speaks

Ask it. The answer is one POST:

``bash curl -X POST https://example.com/mcp \ -H 'content-type: application/json' \ -H 'MCP-Protocol-Version: 2026-07-28' \ -H 'Mcp-Method: server/discover' \ -d '{"jsonrpc":"2.0","id":1,"method":"server/discover", "params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' ``

A DiscoverResult means the server is on the new revision. A 400 whose body is not one of the spec's own error codes means it is handshake-era — fall back to initialize.

One caveat worth knowing: an SDK that recognises the new error codes is not the same as a server that can serve the new revision. Some implementations answer -32022 correctly and then list only handshake-era versions. The versions a server names are the honest answer; the error code alone is not.

Where we track this

The MCP Census asks every endpoint on record which revision it reports, and publishes the answer per server on /lookup and in aggregate on /coverage. The number of servers we have not yet asked is published alongside, so the coverage is never mistaken for the whole ecosystem.

We deliberately do not score servers on their protocol revision. The revision is days old, and marking down working software for that would be a verdict the evidence does not support. See Methodology.