MCP's Largest Revision Yet Lands July 28

The biggest change since launch

On July 28, the Model Context Protocol publishes its next specification version — 2026-07-28, the largest revision of the protocol since it launched. The release candidate has been locked since May 21, and after a ten-week validation window against production workloads, the final spec lands next week.

Gatana will support it. But first, what's actually changing — because this revision is aimed squarely at the people who run MCP in production, and it fixes real problems.

MCP goes stateless

The headline change: the protocol core is now stateless.

• The initialize/initialized handshake is gone, and so is the Mcp-Session-Id header.

• Client metadata travels in _meta fields on every request instead of being negotiated up front.

• A new server/discover method returns server capabilities on demand.

• Server-initiated interactions — confirmation prompts, elicitation — become multi-round-trip requests instead of long-lived SSE streams: the server returns an InputRequiredResult the client can resubmit to any server instance.

If you've ever deployed an MCP server behind a load balancer, you know why this matters. Session affinity, shared session stores, sticky routing — all of it existed to work around protocol-level state. Under the new spec, an MCP server scales like any other stateless HTTP service, behind a plain round-robin load balancer.

The revision leans further into being infrastructure-friendly:

• New Mcp-Method and Mcp-Name headers let routing layers direct traffic without parsing request bodies.

• Results carry ttlMs and cacheScope hints for client-side caching.

• W3C Trace Context propagates through _meta for distributed tracing across SDKs.

• Six SEPs harden authorization, aligning the auth flow with OAuth 2.0 and OpenID Connect — including iss validation per RFC 9207.

• Tool schemas expand to full JSON Schema 2020-12, with composition operators (oneOf, anyOf, allOf) and conditionals.

Extensions in, three features out

The spec also introduces a formal extensions framework — namespaced identifiers, capability negotiation, independent versioning, and a dedicated Extensions Track in the SEP process. Two official extensions ship at launch:

• MCP Apps — servers deliver rendered user interfaces via sandboxed HTML iframes, speaking the same JSON-RPC protocol.

• Tasks — long-running work graduates from an experimental core feature to an extension, with a lifecycle redesigned around stateless operations.

And under the new feature lifecycle policy, three core features receive formal deprecation notices:

• Roots — replaced by tool parameters or server configuration.

• Sampling — use direct LLM provider API integration instead.

• Logging — use stderr or OpenTelemetry instead.

All three keep working for at least twelve months, but the direction is clear — the core protocol is slimming down to what everyone actually uses, and everything else moves to extensions or out of the protocol entirely.

What this means if you're behind Gatana

This is a breaking release — the spec team says so plainly. Clients and servers won't all move at once; some servers you rely on will speak the new version in weeks, others in quarters.

This is exactly the scenario we described when we made the case for MCP: the value sits in the governed boundary, not the wire format — and when the wire format changes, the boundary is what absorbs it. Everything you've defined at that boundary in Gatana stays put:

• Your identity model and how agents authenticate

• Access policies and tool-level permissions

• The audit trail of every invocation

• Server and tool configurations

None of them are tied to a spec version.

We're validating Gatana against the release candidate now, and support for 2026-07-28 will roll out with the ecosystem's Tier 1 SDKs. Our goal is what it always is: clients and servers on either side of the gateway shouldn't have to upgrade in lockstep, and you shouldn't have to care which spec version any given server speaks this quarter.

The protocol just got a lot better at being boring infrastructure. That's the highest compliment a protocol can get — and it's one more reason the boundary you build on it will outlast whatever changes next.

Want the details? Read the full 2026-07-28 release candidate announcement from the MCP team, including the complete list of SEPs and migration notes.