MCP 2026-07-28: What Changed in the New Specification

The Model Context Protocol specification dated 2026-07-28 is the biggest architectural shift the protocol has seen since it launched. If you run an MCP server, this revision changes how your server handles connections, how clients authenticate, and how your infrastructure can scale. This post covers what actually changed, without the marketing language.

The Core Change: MCP Is No Longer Stateful

Every previous revision of MCP was a connection-oriented, session-based protocol. A client would send initialize, the server would respond with initialized, and from that point on the client and server shared a session tracked by an Mcp-Session-Id header. That session had to live somewhere: in memory on a specific server instance, or in shared storage if you wanted to scale across multiple instances.

The 2026-07-28 spec removes that model entirely. MCP is now a stateless, request-response protocol. Each request carries its own protocol version, client identity, and capabilities in a _meta field, so any request can land on any server instance behind a plain round-robin load balancer, with no shared session storage and no sticky routing required.

For anyone running an MCP server behind a load balancer, this is the change that matters most. Session affinity was one of the more annoying parts of operating MCP infrastructure at scale, and it is gone.

Header-Based Routing

Method and tool names now travel in dedicated HTTP headers: Mcp-Method and Mcp-Name. Previously, a gateway or proxy that wanted to route or authorize a request based on which tool was being called had to parse the JSON-RPC body first. With the method and tool name available as headers, infrastructure in front of your MCP server (API gateways, WAFs, custom routing layers) can make routing and authorization decisions without touching the request body.

Multi Round-Trip Requests (MRTR)

Before this revision, a server that needed more information mid-call (asking the user to confirm something, or requesting an additional parameter) had to keep a connection open and send a server-initiated request over it. That model does not survive the move to stateless HTTP.

MRTR replaces it. A server can return a result with resultType: "input_required" describing what it still needs. The client collects the answer and retries the call with the answer included in inputResponses. No held-open connection, no server-initiated push, just an ordinary request-response cycle repeated until the tool has what it needs.

Cacheable List Results

tools/list, prompts/list, resources/list, and resources/read responses can now include ttlMs and cacheScope fields. This lets a client decide how long it can safely cache a server's tool list instead of calling tools/list on every session. For a hosted MCP server handling traffic from many AI clients, this is a meaningful reduction in redundant calls.

Authorization Got Stricter

The authorization changes in this revision are aimed squarely at closing gaps that showed up as MCP adoption grew:

• Authorization servers must now return the iss parameter per RFC 9207, and clients must validate it before redeeming an authorization code. This defends against a class of OAuth mix-up attacks.
• Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD), though it remains functional for backward compatibility during the transition window.
• Client credentials are now bound to the issuing authorization server. A credential issued by one server cannot be replayed against another.
• Dynamic Client Registration gained an application_type setting specifically to fix localhost redirect handling for desktop and CLI clients, which had been a recurring source of friction.

If your MCP server uses OAuth 2.0, this is the section of the spec worth reading closely before you upgrade.

Deprecated, Not Removed (Yet)

The spec authors gave a twelve-month minimum window before removing anything, so none of this breaks a server running today:

• Roots, sampling, and logging are deprecated as subsystems.
• Legacy HTTP+SSE transport is deprecated with a one-year offramp in favor of Streamable HTTP.
• Dynamic Client Registration is deprecated in favor of CIMD but still works.

Deprecated does not mean broken. It means plan a migration path over the next year rather than treating it as urgent this week.

A Formal Extensions Framework

Features that used to live in the experimental core, most notably Tasks, now move into a formal extensions framework identified as io.modelcontextprotocol/tasks, alongside MCP Apps and Enterprise Managed Authorization (EMA). Tasks become poll-based, using tasks/get and tasks/update instead of the older task APIs.

What This Means If You Run an MCP Server

If you host your own MCP server, the practical takeaway is that the stateless core is worth adopting even before you strictly need it. It removes the operational headache of session affinity and lets your server scale the same way any other stateless HTTP service does. The tradeoff the spec authors call out directly: if you were relying on the transport layer to hold implicit state for a client, you now need to model that state explicitly, typically by minting a handle from a tool call and having the client pass it back as an argument on the next call. That is more visible and easier to observe than hidden session state, even if it takes a bit more code up front.

If you host on MCPCore, the platform's MCP server hosting layer handles endpoint provisioning and transport concerns for you, so a spec revision like this is something the platform absorbs rather than something you have to re-architect around yourself.

For the SDK-level changes that come with this spec revision, see our MCP TypeScript SDK v2 migration guide.

---

This summary is based on the official 2026-07-28 specification announcement at modelcontextprotocol.io. Always check the current spec for the authoritative and most up-to-date details.