Stateless MCP server, 2026-07-28 spec: what changes for clients

The MCP specification revision dated 2026-07-28 made the protocol stateless. The headline sounds like a server rewrite, and for server authors it is one. For you, the person who configures Claude Code, Cursor or VS Code, it is mostly a client and server upgrade. This post covers what stays in your config, what moves under it, and which errors tell you that one side is on the old protocol.

Checked against the 2026-07-28 changelog, the Streamable HTTP transport page and the MCP blog on 2026-11-14.

What stays in your config

The URL stays. Streamable HTTP still means one MCP endpoint that accepts POST, and every message from the client is its own POST to that URL. A typical entry looks like this:

claude mcp add --transport http fetchmcp https://fetchmcp.net/mcp \
  --header "Authorization: Bearer $FETCHMCP_API_KEY"

The transport guide explains the difference between stdio and Streamable HTTP. That choice is unchanged.

What moved under the config

initialize is gone. The changelog removes the initialize and notifications/initialized handshake, and it removes protocol-level sessions and the Mcp-Session-Id header from Streamable HTTP. Every request now carries its protocol version and client capabilities in _meta.

server/discover is new. Servers must implement it to advertise their supported versions, capabilities and identity. A client may call it before any other request; it does not have to.

The blog post names the payoff: any request can land on any server instance behind a plain round-robin load balancer, without shared storage.

The headers every request now carries

MCP-Protocol-Version and Mcp-Method go on every POST. Mcp-Name goes on tools/call, resources/read and prompts/get, and holds params.name (the tool or prompt name) or params.uri (the resource URI). The spec calls these headers required for compliance. A fetch call from a 2026-07-28 client looks roughly like this on the wire:

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
Authorization: Bearer YOUR_KEY
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_page_contents

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_page_contents","arguments":{"url":"https://example.com"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}

The headers exist so that load balancers and gateways can route and inspect requests without parsing the JSON body. The client adds them; you never type them.

Errors that point to a version or header problem

Read the HTTP status and the JSON-RPC body together. Under 2026-07-28 the same status can mean different things:

1. 400 with code -32020 (HeaderMismatch). A required header is missing or malformed, or its value differs from the body. If you run a proxy, gateway or wrapper between the client and the server, check that it passes MCP-Protocol-Version, Mcp-Method and Mcp-Name through unchanged.
2. 400 with an UnsupportedProtocolVersionError. The server does not implement the version the client asked for. The error lists the versions it does support. Update whichever side is behind.
3. 404 with code -32601. The server speaks the modern protocol but does not implement that method. A 404 without that JSON-RPC body can come from a legacy HTTP+SSE server that has no modern MCP endpoint.
4. 405 Method Not Allowed on GET or DELETE. An older client is opening a GET stream or ending a session against a server that supports only 2026-07-28. Those mechanisms are not part of the new revision. Update the client.

For a wider runbook from URL to tool call, see debugging an MCP server connection.

Mixed versions: old server, new client

The spec gives clients a fallback. A client that supports both eras may try a modern request first. On a 400, it should read the body: a recognized modern JSON-RPC error means the server is modern, so it corrects the request or retries with a supported version. An empty or unrecognized body means a legacy server, and the client falls back to initialize.

In the other direction, a server that supports only the new revision should ignore an Mcp-Session-Id header and mint no session IDs. Whether your client implements the fallback depends on its version. Read its release notes before you assume it does.

A dropped stream starts over

Last-Event-ID is gone. The revision removes SSE stream resumability and message redelivery. If a response stream breaks mid-request, the in-flight request is lost and the client must send it again as a new request with a new ID. For a slow page fetch, that means the call runs again from the start.

OAuth servers: the preferred registration path

client_id can be an HTTPS URL. The spec deprecates Dynamic Client Registration in favor of Client ID Metadata Documents: the client hosts a JSON document at an HTTPS URL, and the authorization server fetches it. DCR remains available for authorization servers that do not support the new documents.

The recommended order for a client is pre-registered details first, then a metadata document when the authorization server advertises client_id_metadata_document_supported, then DCR, and last a prompt asking you to enter the client details. A server that uses a static bearer key involves no client registration, so this part does not touch that setup.

Deprecated, still working

The HTTP+SSE transport is officially deprecated, with what the blog calls "a year-long offramp". Roots, Sampling and Logging are deprecated too. The blog says they keep working for at least twelve months. A snippet that depends on them is on a clock.

Try it with a real server

FetchMCP API runs a stateless Streamable HTTP server with a bearer key, the same key as its REST API. The MCP server registers 2 tools. The current client configs are in the MCP docs.