What Actually Changed in the 2026-07-28 Spec
The headline change in the 2026-07-28 Model Context Protocol specification is the removal of protocol-level state. The initialize and initialized handshake is gone, and so is the Mcp-Session-Id header that clients previously had to carry across every call. Client information now travels in the _meta field on each request, which means the server no longer needs to remember anything about who is talking to it. Maintainers David Soria Parra and Den Delimarsky locked the release candidate on May 21, 2026, with the final specification scheduled to ship on July 28.
This is a structural change with direct operational consequences. A remote MCP server that previously required sticky sessions, a shared session store, and deep packet inspection at the gateway can now sit behind a plain round-robin load balancer. The spec adds Mcp-Method and Mcp-Name headers specifically so load balancers can route on guaranteed HTTP metadata, plus ttlMs and cacheScope controls for caching list and resource reads. The spec also adds Multi Round-Trip Requests so features like elicitation work without holding a persistent connection open. For any team running MCP as shared infrastructure, the request path just got dramatically simpler to reason about, and the failure modes it introduces are the familiar ones of any stateless HTTP service rather than a bespoke session layer nobody wants to debug at 3am.
GitHub Rebuilt Its Server Before the Ink Dried
On July 23, 2026, five days ahead of the official spec release, GitHub published a changelog announcing that its MCP Server already supports the next specification. The team framed the value plainly: the new stateless core means MCP deployments are now easy to scale. Sessions and initialize are both removed, so clients connect faster and can complete the handshake in parallel where legacy behavior is retained for compatibility.
GitHub described three concrete engineering wins from the migration. It removed Redis-backed sessions, which eliminated database writes during initialization and reads on every subsequent call. It stopped inspecting request payloads at the gateway, reading the values it needs from guaranteed HTTP headers instead. And it reworked elicitation so each step runs as a separate HTTP request, with the Go SDK providing backward compatibility for both old and new clients. The result is lower database I/O and a server that scales horizontally without coordination.
Why the Deprecation Policy Matters More Than the Features
Buried under the stateless headline is a governance change that platform leaders should weigh carefully. The 2026-07-28 spec introduces a formal deprecation policy with an Active, Deprecated, and Removed lifecycle and minimum 12-month deprecation windows. Roots, Sampling, and Logging move to deprecated status under this policy. For the first time, the protocol commits to a predictable clock for breaking changes rather than shipping them whenever a release candidate closes.
That predictability is the difference between MCP being a research toy and MCP being something you standardize a fleet on. Teams that were reluctant to build internal tooling against a fast-moving protocol now have a contract. A capability marked deprecated today will still function a year from now, which lets platform engineering plan migrations against a calendar instead of reacting to surprise removals. This is the kind of maturity signal that moves a protocol from experimental adoption into procurement conversations.
The Extensions and Schema Upgrades
Beyond statelessness, the spec formalizes an extensions framework using reverse-DNS identifiers, which lets vendors add capabilities without polluting the core protocol. Two extensions arrive alongside it. MCP Apps introduces server-rendered HTML interfaces, giving tools a way to present richer output than plain text. The Tasks extension graduates from an experimental core feature into a first-class, optional capability that clients can negotiate rather than assume.
On the schema side, tool definitions gain full JSON Schema 2020-12 support, including the composition operators oneOf, anyOf, and allOf. That closes a long-standing gap where MCP tools could not express the same input contracts that modern APIs take for granted. The spec also propagates W3C Trace Context in _meta, so agent calls can be traced end to end through existing observability pipelines. One breaking detail worth flagging for implementers: the error code for a missing resource changes from -32002 to -32602.
What Platform Teams Should Do Now
The migration risk here is unusually low, which is the point. Beta SDKs for Python, TypeScript, Go, and C# already ship support for the 2026-07-28 spec, and GitHub reports that all tier-one SDKs preserved backward compatibility. Existing clients keep working without changes. Teams operating remote MCP servers get to delete infrastructure they built to work around the old stateful model, including session stores and sticky-session gateway rules.
For engineering leaders, the decision framework is straightforward. If you run MCP as an internal platform capability, plan to adopt the stateless core because it collapses your operational surface and cuts database load. If you consume third-party MCP servers, verify your SDK is on a beta that supports the new spec and move before the deprecated features age out. Either way, the July 28 date is a natural checkpoint to audit which MCP surfaces you depend on and how they are secured.
The Bigger Signal for Agent Infrastructure
MCP going stateless is a quiet admission that agent tooling is becoming production infrastructure rather than a prototyping convenience. The design choices in this release, from load-balancer-aware headers to trace context propagation to a real deprecation policy, are the choices you make when servers run at fleet scale under an SRE team. The protocol is being reshaped to fit the operational reality of the companies deploying it.
For enterprise engineering organizations, the takeaway is that the cost of running agent tooling is falling into the same well-understood envelope as any stateless HTTP service. That changes the build-versus-buy math. Standing up an internal MCP gateway no longer requires the session-management machinery that made it a meaningful project. The authorization hardening in this release, including issuer validation per RFC 9207 and OpenID Connect application_type declarations, further pushes MCP toward something a security team can sign off on. Taken together, the stateless core, the deprecation policy, and the tightened auth story turn MCP into a protocol a platform organization can adopt with the same confidence it would extend to any other production dependency, which is exactly the bar that agent tooling now has to clear.
