MCP Just Rewrote Its Core Architecture. Here Is What Changed.

MCP's 2026-07-28 spec rewrote the protocol from stateful to stateless. Here is what changes for anyone running, scaling, or trusting an MCP server.

MCP just rewrote its own wire protocol, and the change is architectural, not cosmetic. The Model Context Protocol's Lead Maintainers confirmed it in a roadmap post published August 22, 2026: the 2026-07-28 specification release moved MCP from a stateful, bidirectional protocol to a stateless request/response core, so a server can scale horizontally without holding any per-session state. If you run an MCP server, integrate one into your agent, or simply trust one your team already approved, three things moved under you at once: how sessions work, how the server scales, and how its authorization flow registers clients.

The mechanism is precise, not a marketing description. Two Specification Enhancement Proposals did the work. SEP-2567 removed the Mcp-Session-Id header and protocol-level sessions from the Streamable HTTP transport, and SEP-2575 removed the initialize/initialized handshake entirely, moving the protocol version and client capabilities into a _meta field that now rides on every request instead of being negotiated once at connection time. The maintainers describe the payoff directly: "any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage." That single sentence is the whole operational story for anyone who runs a server today.

Sources: The 2026-07-28 Specification (Model Context Protocol Blog), Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

This argument favors a category we build in, so read it with that disclosed: we make TLM Forge, a process layer that gates AI-driven changes before they ship, and a protocol rewrite of this size is exactly the kind of new fact a vetting process is supposed to catch before it becomes an incident. The vendor-neutral claim underneath it stands on its own: the servers your team approved under the old protocol are not the same servers anymore, even if nobody touched their code.

What stateless actually removed

The 2026-07-28 specification removed the entire session handshake: no more initialize call, no Mcp-Session-Id header, no protocol-level concept of a connection that persists between calls. Before July 28, every MCP session opened with that handshake instead. A client sent initialize, the server replied with its capabilities, the client confirmed with notifications/initialized, and only then could either side call a method. The server minted a session and returned it in the Mcp-Session-Id header, and the client had to send that header back on every subsequent call for the life of the connection. That header was the whole reason MCP servers needed sticky infrastructure: whichever instance issued the session was the only instance that could serve it, because the session lived in that instance's memory or in a store wired specifically to it.

Every request now carries its own protocol version, client identity, and capabilities inline in a _meta field, and a new server/discover call, which every server must implement and a client may use optionally, lets a client learn what a server supports before sending anything else. A server that needs to remember something across calls, a long-running job, a cursor into a large result set, mints its own explicit handle and passes it back as an ordinary tool argument. State did not disappear. It moved out of the protocol and into whatever the server or the application chooses to do with it.

Sources: Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

Where the state actually went

The protocol also removed the ways a server used to reach back into the middle of a call. Server-initiated requests such as roots/list, sampling/createMessage, and elicitation/create are gone, replaced by a Multi Round-Trip Requests pattern under SEP-2322. Instead of a server pausing a call to ask the client something, it now returns a result tagged input_required with the specific fields it needs. The client answers by retrying the original request with those answers attached. Nothing is held open in between. A connection that used to sit mid-conversation waiting on the client is now, from the server's point of view, just another completed request.

Sources: Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

Long-running work got the same treatment. Tasks, which had lived as an experimental core feature, moved out into an official extension under SEP-2663. The old design blocked on tasks/result until a job finished. The new one polls: a client calls tasks/get to check progress and tasks/update to push input into a running task, and a server can hand back a task handle unprompted rather than requiring the client to opt in ahead of time. Tasks sits alongside MCP Apps and Enterprise Managed Authorization as one of the first citizens of a formal extensions framework, the mechanism the 2026-07-28 release introduced for shipping new capabilities without changing the core spec.

Sources: The 2026-07-28 Specification (Model Context Protocol Blog)

None of this makes state unnecessary, it just relocates it. A coding agent that needs to remember what a tool call returned three turns ago never got that memory from the MCP session in the first place, and now the protocol is explicit about it: continuity is the application's job, not the wire's. That is the same curation problem covered in context management for AI coding, applied one layer down. Deciding what belongs in a live context window and what belongs in durable memory was already the integrator's call; a stateless MCP core just removes the option of quietly letting the protocol do it for you.

Five concrete patterns mark integration code that still assumes the protocol behaves the old way. Check for these directly:

• Code that reads or sets the Mcp-Session-Id header on outgoing requests
• Client logic that blocks on a one-time initialize handshake before the first tool call
• A handler that treats roots/list or sampling/createMessage as a server-initiated push instead of an input_required result to retry
• OAuth 2.0 Dynamic Client Registration wired in as the only client registration path
• A long-running tool call that blocks on tasks/result instead of polling tasks/get

The scaling case, with a receipt

The scaling argument is not theoretical. Google Cloud engineers documented the old failure mode plainly: standard round-robin load balancers do not know which container holds which in-memory session, so a client that got routed to a different pod on its next call received a 400 Session Not Found error. Teams worked around it with sticky session affinity at the load balancer, which prevents even traffic distribution and makes autoscaling inefficient, and if a pod restarted mid-session, the state vanished and active requests failed. None of those three problems is specific to one vendor's infrastructure. They are generic consequences of pinning protocol state to a single process.

Sources: Scaling AI Agent Infrastructure with the MCP Stateless updates (Google Developers Blog)

GitHub's own MCP server is the concrete before-and-after. Its July 23, 2026 changelog entry for 2026-07-28 support states it plainly: "Removed Redis sessions: Database writes on initialize are gone, and database reads are gone from every call, which makes things snappier without users losing anything." That is a real production server dropping a dependency and two categories of database operation on every single request, not a hypothetical. The protocol's adoption gives that example weight. The Lead Maintainers report close to half a billion downloads a month across the Tier 1 SDKs, with the TypeScript and Python SDKs each having crossed one billion total downloads, so a change to how sessions work touches an enormous amount of already-deployed infrastructure at once.

Sources: GitHub MCP Server supports the next MCP specification (GitHub Changelog), The 2026-07-28 Specification (Model Context Protocol Blog)

What changes in your auth flow

Authorization tightened at the same time sessions loosened. SEP-2468 calls for authorization servers to include an iss parameter in the authorization response per RFC 9207, and requires MCP clients to validate that issuer against the one they recorded before they redeem an authorization code. SEP-2352 adds a related rule: client credentials are bound to the issuer that granted them, a client must key stored credentials by issuer identifier, must not reuse them against a different authorization server, and must re-register if the authorization server changes. Both close the same category of mistake: a client trusting a token or a code without confirming which authorization server actually vouched for it.

Sources: Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

Client registration changed too. OAuth 2.0 Dynamic Client Registration, the mechanism most MCP clients used to register themselves with an authorization server automatically, is now formally deprecated in favor of Client ID Metadata Documents, a scheme where a client's identity is a URL the authorization server can fetch and verify rather than a record created through an open registration endpoint. Dynamic Client Registration still works for authorization servers that have not adopted the new scheme, so nothing breaks on the day of the spec change, but it is on the clock. Anthropic's own rollout notes for Claude point the same direction: enterprise-managed authorization through an identity provider, private MCP tunnels instead of public exposure, and authorization that lines up with how teams already run OAuth 2.0 and OIDC through providers like Entra or Okta, rather than MCP inventing its own pattern.

Sources: Bringing the MCP 2026-07-28 spec to Claude (Claude Blog), Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

Governance changed before the protocol did

The protocol did not restructure itself. Governance changed first, and the August 22 roadmap post is explicit about it: "We formally adopted a Contributor Ladder, Working Groups now triage SEPs in their own area, and the specification has a proper feature lifecycle and deprecation policy." That last piece is not a vague promise. SEP-2596 defines three states, Active, Deprecated, and Removed, with a minimum twelve-month deprecation window before anything in Deprecated status can be pulled, and a public registry that tracks exactly which features are in which state. The HTTP+SSE transport and the Roots, Sampling, and Logging features are already in that Deprecated state as of this release.

Sources: The New MCP Roadmap (Model Context Protocol Blog), Key Changes, MCP Specification 2026-07-28 (modelcontextprotocol.io)

The people making these calls changed too, earlier in the year. In April 2026 the project added Clare Liguori, a Senior Principal Engineer at AWS who works on agentic developer tooling, as a Core Maintainer, and promoted Den Delimarsky, a Member of Technical Staff at Anthropic, to Lead Maintainer. The maintainers said the goal was "to make sure the protocol could keep growing without any one person becoming a bottleneck." Den Delimarsky co-authored the August roadmap post alongside fellow Lead Maintainer David Soria Parra, so the same people who expanded the review capacity are the ones now shipping changes at this pace.

Sources: Expanding the MCP Maintainer Team (Model Context Protocol Blog)

For a team that already built a process to vet MCP servers before connecting them, this is the update that process needs to ingest. How to vet MCP servers before you trust them covers admitting a server as a supply-chain decision: an allow-list, a review before connecting, runtime monitoring, a documented kill-switch. A protocol-level rewrite is exactly the kind of event that should re-trigger that review, even for a server whose code never changed, because its authorization flow, its session behavior, and the transport it is allowed to use may all have moved underneath it. TLM Forge applies the same discipline to code: a decision does not stay approved by default once the ground it was approved on shifts, and a protocol rewrite is precisely that kind of shift.

The relocation of state is also a reminder of where continuity has to live now that the wire will not carry it for you. MCP's session was never a substitute for memory. It was connection-scoped plumbing that disappeared the moment a client disconnected, but plenty of tooling grew up leaning on it anyway. That continuity has to be built deliberately, by whatever sits above the protocol, not assumed as a side effect of a session that no longer exists by design. MemX, from the same team behind TLM Forge, is a private, persistent memory layer built for a different, personal use case: an individual's own photos, documents, voice notes, and messages, not agent session state.

MCP's core is smaller and plainer than it was a month ago, and that is the point. A stateless request/response core is easier to scale, easier to host, and easier to reason about than a protocol that quietly expected every server to be a long-lived process with a memory of its own. The cost lands on whoever built tooling, trust decisions, or infrastructure around the version that no longer exists. Read the roadmap post, check your integration code against the six rows above, and treat the servers your team already approved as due for a second look, not because anything about them got worse, but because the protocol they run on already changed.