Posted Date : 04 Jul 2026
The Model Context Protocol is about to undergo the largest revision since it launched. On May 21, 2026, the MCP maintainers published the release candidate for the 2026-07-28 specification, and the final version is scheduled to publish on July 28, 2026. The ten-week window in between exists so SDK maintainers and client implementers can validate the changes against real production workloads before the spec is locked.
If your team builds or operates MCP servers, this isn't a release to skim. It touches the transport layer, the authorization model, and the assumptions your infrastructure makes about state. Here's what's changing and what to do about it.
Since launch, a Streamable HTTP client has had to establish a session before doing anything else. The server would return an Mcp-Session-Id, and the client carried that ID into every subsequent request. That model works fine for local development, but it creates real operational friction in production: sticky sessions, shared session stores, and gateways that need to inspect MCP traffic just to route it correctly.
The 2026-07-28 release candidate removes protocol-level sessions entirely (SEP-2567). The initialize/initialized handshake is also gone (SEP-2575)—protocol version, client info, and capabilities now travel in _meta on every request, and a new server/discover method lets clients fetch server capabilities on demand instead of upfront.
The practical upshot: any available server instance can handle any request. A remote MCP server that previously needed sticky sessions and deep packet inspection at the gateway can now sit behind an ordinary round-robin load balancer. Scaling and debugging MCP servers starts to look like scaling and debugging any other web service.
This doesn't mean your application has to give up state—it means state moves out of the protocol and into your application layer. If a server needs to remember something between tool calls (a repository path, a browser session, or an open task), it mints an explicit handle and hands it back to the model, which passes it along as an ordinary tool argument on later calls. That's arguably a better pattern than hidden session state anyway, since the model can reason about the handle, compose it across tools, and pass it between steps explicitly.
Three smaller but consequential changes round out the transport story:
Mcp-Method and Mcp-Name headers, so load balancers, gateways, and rate-limiters can route on the operation being performed without needing to parse the request body. Servers reject requests where the headers and body disagree, so the headers are trustworthy rather than advisory.ttlMs models on HTTP's Cache-Control. Clients know exactly how long a tools/list response stays fresh and whether it's safe to share across users—a long-lived SSE stream is no longer the only way to find out that a list changed._meta is now formally documented, with fixed key names for traceparent, and. A trace that starts in a host application can now follow a tool call through the client SDK, the MCP server, and whatever it calls downstream and show up as a single trace in tools teams already use, like OpenTelemetry.Together, these changes make MCP traffic behave much more like ordinary HTTP traffic—which is exactly the point.
MCP servers were already OAuth 2.1 resource servers as of the 2025-11-25 spec, but the new release tightens that considerably, moving MCP's authorization model closer to how OAuth and OpenID Connect are actually deployed in the wild. For teams thinking about credential scoping, supply-chain verification, or the confused-deputy problem in delegated tool calls, this release makes several existing best practices easier to implement rather than introducing new ones from scratch—Resource Indicators (RFC 8707), for example, map directly onto that delegation problem.
Rather than growing the core specification indefinitely, MCP is formalizing an extensions framework so new capabilities can ship, stabilize, and iterate on their own timeline instead of being bundled into every core release. Two extensions ship alongside this release:
Alongside extensions, MCP is introducing a formal feature lifecycle policy: every feature moves through Active, Deprecated, and Removed states, with a minimum of twelve months between deprecation and the earliest possible removal. A standards track proposal can no longer reach final status until a matching scenario lands in the conformance suite—the same suite the new SDK tier system will score official SDKs against. The goal is straightforward: let the protocol keep evolving without breaking what teams have already built on top of it.
A few points worth being precise about, since the trade press coverage of this release has occasionally blurred them:
If you operate MCP servers in any environment that matters, this is a good moment to:
MCP started as a practical way to wire AI applications up to tools, data, and services. This release is the protocol maturing into infrastructure teams can build on with more confidence: it runs on commodity HTTP infrastructure, exposes fewer hidden assumptions about state, and gives implementers a clear, versioned path for future changes rather than a moving target. There's real migration work here, particularly around session assumptions and authorization—but the direction is a healthier one for anyone running MCP servers in production.
The release candidate is available now if you want to start testing. The final specification publishes July 28, 2026.
Have a project in mind? Let’s build something amazing together.
Webbitech — A Leading Web Design & Web Development Company with 15+ Years of SEO & Digital Marketing Expertise, Delivering Countless Success Stories
From idea to execution, we help businesses create high-performing websites and applications.
Start your journey today and take your brand to the next level.
Get Free Consulting
Get In Touch
