The stateless MCP specification: what changes for teams running MCP servers

The Model Context Protocol's 2026-07-28 revision is the largest change to the protocol since it launched. MCP moves from a stateful, bidirectional protocol to stateless request and response, adds headers that gateways can route and authorise on, tightens the OAuth flow, and puts several features on a formal path to removal. About 11 weeks on, SDKs and servers are adopting it, and teams that run or depend on MCP servers need a plan for the transition.

What the new revision changes

The maintainers' release post calls the stateless core "the highlight of this release". The changelog lists the details against the previous revision, 2025-11-25.

No handshake, no sessions

The initialize and initialized exchange is gone, and so is the Mcp-Session-Id header. Every request now carries its protocol version and client capabilities in _meta, and clients should identify themselves on each request. Servers must implement a new server/discover call that advertises versions and capabilities, though clients don't have to call it.

The practical effect, in the maintainers' words, is that "any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage." Servers that need state across calls are told to mint an explicit handle in a tool result and have the model pass it back as an argument.

Multi Round-Trip Requests

Server-initiated requests such as elicitation, sampling and roots/list used to need a held-open stream. They are replaced by Multi Round-Trip Requests: the server returns a result of type input_required listing what it needs, and the client retries the original call with the answers attached.

Headers for gateways

Streamable HTTP requests must now include Mcp-Method and Mcp-Name. The release post says that a "gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies."

Cacheable lists

Results from tools/list, prompts/list, resources/list, resources/read and resources/templates/list must carry ttlMs and cacheScope. Servers should also return tools in a deterministic order, which the changelog says improves client-side caching and model prompt cache hit rates.

Authorisation hardening

• Clients must validate the iss parameter (RFC 9207) when an authorisation server returns it, before redeeming a code. The post says this "closes an authorization-server mix-up hole."
• Client credentials are bound to the authorisation server that issued them, and must not be reused with another.
• Clients set application_type during Dynamic Client Registration, which stops localhost redirects for desktop and command-line apps from being rejected.
• Dynamic Client Registration itself is deprecated in favour of Client ID Metadata Documents. It still works for backwards compatibility.

Deprecations with a timetable

Roots, Sampling and Logging are deprecated, along with the legacy HTTP+SSE transport. The revision also adopts a formal lifecycle policy with a minimum twelve-month deprecation window, so deprecated features keep working for at least a year. The changelog suggests migrations: pass directories through tool parameters instead of Roots, call model provider APIs directly instead of Sampling, and log to stderr or use OpenTelemetry instead of Logging.

Analysis: what is new, and what is hype

Genuinely useful for operators. Statelessness removes the hardest part of running MCP servers at scale: sticky sessions and shared session storage. Header-based routing means an ordinary HTTP gateway can make decisions about which tool is being called without parsing the body. Both make MCP behave more like the rest of a company's HTTP estate, which is easier to secure and monitor.

A real security improvement, not a complete one. Issuer validation and issuer-bound credentials close specific OAuth weaknesses. They don't address the bugs that dominate MCP security advisories, such as servers that fetch attacker-chosen URLs or pass arguments into shell commands. Those are implementation problems the protocol can't fix.

Headers are a convenience, not a control. A gateway that authorises on Mcp-Name must also check that the header matches the body. The changelog adds a HeaderMismatchError to the schema for exactly this case. Treat the headers as routing hints you verify, not as trusted input.

Breaking changes cost something. The release post acknowledges "some migration cost, especially for developers that did depend on session identifiers." Removing SSE stream resumability also means a broken stream loses the in-flight request, which clients must re-issue. Expect a period of mixed versions in which some servers and clients speak only the old revision.

Telemetry gets a defined place. The changelog documents OpenTelemetry trace context propagation through _meta keys (traceparent, tracestate, baggage). That makes it easier to follow one agent action across a client, a gateway and an MCP server in one trace.

What it means for engineering and security leaders

Most organisations don't run one MCP deployment; they have dozens of servers, configured by individual developers, in different AI tools. The new revision makes centralising them more attractive, because a stateless server behind a standard gateway is simpler to operate than one per laptop. It also makes the inventory question more urgent: during the transition you need to know which servers and clients speak which revision.

For security teams, the deprecation of Dynamic Client Registration and the new issuer rules are a good moment to review how MCP clients authenticate to internal services, and whether tokens are scoped and stored centrally or scattered across machines.

Practical takeaways for this week

• List the MCP servers your teams run or depend on, and which SDK and protocol revision each uses.
• For servers you own, check the migration notes in your SDK. Replace any reliance on session identifiers with explicit handles passed as tool arguments.
• If you put a gateway or WAF in front of MCP traffic, use Mcp-Method and Mcp-Name for routing and metering, and reject requests whose headers don't match the body.
• Review OAuth clients: validate iss, key stored credentials by issuer, and plan the move from Dynamic Client Registration to Client ID Metadata Documents.
• Stop adopting Roots, Sampling and Logging in new work, and note the twelve-month window for existing uses.
• Propagate trace context through _meta so MCP calls appear in the same traces as the rest of an agent's work.

Where SpanDock fits

The SpanDock MCP gateway, on the Premium and Enterprise plans, gives every computer's AI tools one MCP server and connects it, on your server, to your organisation's MCP connectors. Each call passes your permissions and rules and is recorded, and connector credentials stay on the server, never sent to computers.