MCP goes stateless on July 28. Your existing connections don't have to wait.

A short checklist before July 28

• Inventory your MCP clients and check which protocol version each one currently negotiates, most SDKs log or expose this on connect.
• Ask the vendors behind servers you call directly whether they've committed to a `2026-07-28` timeline, and what happens to your integration if they haven't shipped it yet.
• Check for Roots, Sampling, or the logging capability in anything you've built. None of it breaks on July 28, but the twelve-month deprecation clock starts now.
• If you use MCP Tasks, plan to move off `tasks/list` specifically, it's removed outright, not just deprecated.
• Put a gateway in front of anything you don't control the upgrade timeline for. It's the only lever that turns "wait for twenty vendors" into "upgrade one endpoint."

On July 28, 2026, the Model Context Protocol specification ships its most substantial revision since launch. The stateful core that every MCP client and server has been built against — the `initialize` handshake, the `Mcp-Session-Id` header, sticky routing to a single server instance — is replaced by a stateless design built for horizontal scale. Authorization is hardened across six Specification Enhancement Proposals. Extensions become a formal, versioned part of the specification. Three long-standing capabilities move into deprecation.

These are not incremental changes. For any organization whose AI agents already talk to MCP servers, this release changes what "talks to" means at the wire level. The relevant question for engineering and security leaders isn't whether the specification is well designed, it's who is responsible for upgrading your existing connections, and on what timeline.

What actually changes on July 28

The headline change is architectural: MCP moves from a stateful protocol, where a client and server negotiate capabilities once via `initialize` and then share a session, to a stateless one, where every request carries what the server needs to handle it. The practical effects:

• No more handshake. `initialize`/`initialized` and the signed `Mcp-Session-Id` header are gone on the new path. Client info and capabilities travel in `_meta` on every request instead.
• A new discovery method. `server/discover` replaces the upfront capability exchange, so a client can learn what a server supports without a session-bound round trip.
• Any instance can answer. Because nothing is pinned to a session, a stateless MCP server can sit behind a plain round-robin load balancer instead of requiring sticky routing and a shared session store.
• State goes explicit. Servers that need cross-request state (a shopping basket, a long-running search) return an application-level handle, like `basket_id`, that the model passes back as a tool argument, rather than hiding it in a hidden session.
• Routing and caching headers. New `Mcp-Method` / `Mcp-Name` headers let infrastructure route requests without inspecting the body, and `ttlMs` / `cacheScope` fields on list and read responses give clients an explicit caching contract.
• Trace context, formally. W3C Trace Context (`traceparent`, `tracestate`, `baggage`) is documented as the standard way to propagate a request across an MCP call chain, with locked key names for OpenTelemetry compatibility.

Authorization gets six new SEPs

The second major thread tightens MCP's alignment with OAuth 2.1 and OpenID Connect. Read together, the six SEPs close the gap between "an MCP server accepts a bearer token" and "an MCP server behaves like a properly scoped OAuth resource server":

• Protected Resource Metadata (RFC 9728). A server publishes a discovery document telling clients which authorization server issues its tokens, instead of clients guessing or hardcoding it.
• Resource indicators (RFC 8707). A client states which MCP server a token is for when it requests one, so a token minted for server A can't be replayed against server B, the classic confused-deputy pattern.
• Client ID Metadata Documents (CIMD). A `client_id` can now be an HTTPS URL that resolves to a signed metadata document, giving a new third-party MCP client a way to register itself without the unauthenticated free-for-all of Dynamic Client Registration, which is now deprecated as the preferred path.
• Issuer validation (RFC 9207). Clients must check the `iss` parameter on an authorization response against the issuer they expected, closing mix-up attacks where a malicious authorization server answers on another server's behalf.
• Plus clarified handling of refresh tokens from OpenID Connect servers and scope accumulation across `.well-known` discovery.

Extensions become first-class: MCP Apps and Tasks

Extensions graduate from an informal pattern to formal infrastructure: reverse-DNS identifiers, independent versioning, and dedicated repositories with delegated maintainers. Two ship as official extensions on day one.

• MCP Apps. Servers can declare a sandboxed HTML UI template ahead of time, so a host can prefetch, cache, and security-review it before anything renders, rather than trusting arbitrary markup at call time.
• Tasks. Long-running work, most visibly human-in-the-loop approvals, moves out of the core spec into its own extension. The blocking `tasks/result` call is gone; clients now poll `tasks/get`, `tasks/update`, and `tasks/cancel` against a task handle. `tasks/list` is removed outright, since listing every task can't be scoped safely without a session to scope it to.

What's quietly deprecated

Three capabilities enter formal deprecation under a new feature lifecycle policy. These are annotation-only for now, methods keep working, but the clock on a required twelve-month runway starts July 28:

The gap this creates for anyone running MCP today

SDK maintainers had a ten-week release-candidate window, from May 21 to July 28, to validate against real workloads, and Tier 1 SDKs are expected to land support inside it. That's a reasonable timeline if you author one MCP server and one SDK dependency.

It's a much harder timeline if your agents call MCP servers you don't control. A typical team's AI stack isn't one server, it's GitHub, Slack, Azure DevOps, Vercel, a CRM, a support desk, a handful of internal APIs wrapped as MCP, easily twenty-plus independent MCP endpoints per organization. Each one upgrades to the new spec on its own vendor's schedule, if it upgrades at all. If your agent talks to those servers directly, your effective "MCP readiness" on July 28 is whichever of those twenty-plus vendors is slowest, and you have no way to accelerate any of them.

How airlock is already speaking 2026-07-28

airlock's org-wide MCP endpoint is the thing your AI client actually negotiates the protocol with. Every proxied connection, GitHub, Azure DevOps, Slack, Vercel, your internal OpenAPI services, sits behind that one endpoint. That means the endpoint's protocol support is your organization's protocol support, and we've been building toward July 28 since the release candidate dropped:

• Dual protocol-version dispatch. The endpoint reads the `MCP-Protocol-Version` header on every request. A `2026-07-28` request gets the full stateless path: client identity and capabilities from `_meta`, no session header minted or read, `Mcp-Method` / `Mcp-Name` response headers set, the deprecated logging capability quietly not advertised. Anything on an older version, or no header at all, gets the classic `initialize` handshake and a signed session, byte-for-byte unchanged. Nothing that works today stops working on July 28.
• `server/discover`, implemented. The RC's consolidated discovery method is live on the stateless path, returning the supported protocol version, mirrored capabilities, and the mandatory caching hints the new spec requires.
• W3C trace context, end to end. Inbound `traceparent` / `tracestate` / `baggage` are validated, logged against the request, forwarded to upstream MCP servers and downstream APIs, and surfaced back to the client as `_meta.correlation_id` and `_meta.trace_id` on every new-spec response. `baggage`, which can carry caller-defined key/values, is stripped before it ever crosses a third-party trust boundary.
• MCP Apps, live. In hosts that support MCP Apps, an approval card renders pending requests directly in the agent, and a sandboxed widget broker proxies upstream MCP Apps UI through a policy-enforced frame with a server-authored CSP, no upstream widget gets to declare its own security policy unchecked.
• Tasks, on the new extension contract. Approvals are addressable as tasks: `tasks/get`, `tasks/update`, and `tasks/cancel` work against the handle airlock stamps on every approval request. Clients that haven't opted into the extension keep getting the legacy polling payload, so the migration is additive, not a cutover.
• Every authorization SEP in this release, already shipped. Protected Resource Metadata discovery, RFC 8707 resource indicators on upstream token requests, RFC 9207 issuer validation against mix-up attacks, and Client ID Metadata Documents as a trust source for third-party clients, alongside the existing vendor allowlist and per-org admin approval, are already how airlock brokers every credential it holds.

What "ready on day one" means for your existing connections

This is the part worth sitting with: you don't upgrade GitHub, Azure DevOps, Slack, or Vercel. You never could. What you can upgrade is the one endpoint your agent actually calls. Point an MCP-compatible client, ChatGPT, Claude, Cursor, or an agent you built, at your organization's airlock endpoint, and it can send `MCP-Protocol-Version: 2026-07-28` starting the day the spec ships. Every connection already sitting in that catalog inherits the new dispatch, the hardened auth, the trace propagation, and the extensions framework, regardless of whether the vendor behind that specific connection has shipped a single line of new-spec code.

That's the difference between waiting on twenty-plus vendors and depending on one gateway you can actually verify. It's also, not incidentally, the same reason a gateway is the right place to enforce policy, audit, and least privilege in the first place, argued in more depth in our MCP governance guide.

Frequently asked questions

Does anything break in my current MCP setup on July 28? No. Protocol version is negotiated per request, and the spec update is a revision, not a fork. A client that doesn't send the new `MCP-Protocol-Version` header keeps getting the legacy `initialize` handshake it already expects.

Do I need to rewrite my own MCP servers before July 28? Only if you want to expose the new stateless behavior yourself. Tier 1 SDKs are expected to ship compatible support during the release-candidate window, and deprecated features carry a minimum twelve-month runway before removal, so there's no cliff on launch day.

How does airlock handle a third-party MCP server that hasn't upgraded yet? Your agent's protocol conversation happens with airlock's org-wide endpoint, not directly with GitHub's or Azure DevOps' own server. Whatever protocol version the upstream vendor currently supports is airlock's problem to manage behind that endpoint, not something your agent, or you, has to track vendor by vendor.

Is this specific to airlock customers, or does it apply to anyone running MCP? The spec changes apply to everyone; July 28 is a protocol release, not a vendor announcement. What's specific to airlock is that the org-wide endpoint in front of your existing connections already speaks it, so you don't have to wait on each individual vendor to catch up.

The bottom line

July 28, 2026 is the biggest change to how AI agents talk to tools since MCP launched: stateless by default, harder to spoof, and extensible without touching the core spec again. That's a genuinely good direction. It's also, for anyone with more than one or two MCP connections, an integration problem measured in vendors, not in code. A gateway that already speaks the new spec turns that vendor-by-vendor wait into a single upgrade you control, on day one.

Related readingMCP governance: what it is and how to do it rightMCP governance decides which servers AI agents can use, what they can do, and what gets logged. The risks, the frameworks worth aligning to, and a practical checklist.→