In August, a fintech's engineering lead spends a Saturday debugging why their support agent keeps losing context mid-conversation whenever the load balancer routes a follow-up request to a different MCP server instance than the one that handled the first message. Every instance is healthy, the model is fine, nothing has crashed. A request simply lands on a machine that has no idea a conversation with that ID exists, because the entire session lived only inside the process that opened it. Three weeks earlier, the Model Context Protocol's maintainers had shipped the fix for exactly this class of problem, as part of the biggest specification revision since MCP launched in November 2024. Most teams running MCP servers in production haven't read it yet.
What actually changed in the MCP 2026-07-28 specification?
The short version: MCP became stateless, authorization got materially harder to misuse, and the protocol picked up a formal deprecation policy so future breaking changes come with a runway instead of a surprise. The official changelog, published against the previous 2025-11-25 revision, lists nine major changes, and three matter for almost anyone running an MCP server in production.
- **Protocol-level sessions are gone.** The `Mcp-Session-Id` header and the `initialize`/`notifications/initialized` handshake are removed. Every request now carries its own protocol version and client capabilities inline, in `_meta`, so no request depends on a prior one having set up shared state.
- **A new `server/discover` RPC replaces the old handshake's job.** Servers must implement it to advertise supported protocol versions, capabilities and identity; clients can call it up front for version selection instead of negotiating a session first.
- **`subscriptions/listen` replaces the HTTP GET stream and `resources/subscribe`/`unsubscribe`.** It's a single long-lived stream clients opt into per notification type, which is a cleaner model than the old always-on GET connection.
- **SSE stream resumability is removed.** A broken response stream now means re-issuing the request with a new ID, not resuming where it left off, a direct consequence of no longer tracking per-connection state server-side.
- **A Multi Round-Trip Requests (MRTR) pattern replaces server-initiated calls** like `roots/list` and `sampling/createMessage`: instead of the server calling back into the client mid-request, it returns an `input_required` result and the client retries the original request with the answer attached.
Why was MCP session-based in the first place, and why did that become a problem?
MCP's original design mirrored how a lot of stateful APIs work: a client opens a session, the server remembers who it's talking to, and subsequent requests reference that shared context. That's a reasonable default for a single server process talking to a single client. It breaks down the moment you put more than one server instance behind a load balancer, which is exactly what production traffic requires.
The failure mode is sticky routing. If session state lives inside one process's memory, every request in that session has to be routed back to that same process, or the request fails because the receiving instance has never heard of that session ID. Autoscaling, rolling deploys and simple load-balancer failover all fight against that constraint, because they all want to treat instances as interchangeable. David Soria Parra, MCP's co-inventor, framed the fix plainly: the state doesn't disappear, it moves onto the wire, into the request itself, so any instance behind a plain round-robin load balancer can handle any request. The official MCP blog post announcing the release puts it the same way: every request is now self-describing.
Session-based MCP vs. the 2026-07-28 stateless model
What this actually changes for a server you operate:
| Behavior | 2025-11-25 (session-based) | 2026-07-28 (stateless) |
|---|---|---|
| Request routing | Sticky: a session's requests must reach the same server instance | Any instance can handle any request; plain round-robin load balancing works |
| Client identity | Established once at `initialize`, implicit afterward | Sent on every request via `_meta` (`clientInfo`, `clientCapabilities`) |
| Broken connection recovery | Resumable via `Last-Event-ID` and SSE event IDs | Not resumable; client re-issues the request with a new ID |
| Server-initiated calls (e.g. sampling) | Server calls back into the client mid-request | Server returns an `input_required` result; client retries with the answer |
| List endpoint results | Can vary per connection | No longer vary per-connection; cacheable via required `ttlMs`/`cacheScope` fields |
Source: Model Context Protocol — Key Changes, 2026-07-28 specification changelog.
What is the enterprise-managed authorization extension, and why does it matter?
It lets an organization designate its own corporate identity provider as the authoritative gatekeeper for MCP server access, so governance runs through corporate credentials instead of personal accounts nobody's IT team can audit. Anthropic and other maintainers built the Enterprise Managed Authorization extension with identity provider Okta, and it's exactly the kind of governance gap that has kept a lot of enterprise security teams from approving MCP in the first place: a developer's personal API token authorizing an agent's access to a production system is not something a compliance review signs off on twice.
The spec also closes a real vulnerability class independent of that extension. Authorization responses must now include the `iss` parameter per RFC 9207, and MCP clients must validate it against the recorded issuer before redeeming an authorization code, per SEP-2468. Den Delimarsky, MCP's lead maintainer, was careful to clarify this closes an entire class of mix-up attacks, where a client can be tricked into associating an authorization response with the wrong identity server, rather than a specific known exploit already in the wild. Closing the class before it's exploited is still the right call for anything touching real credentials.
Do you need to migrate your existing MCP integrations right now?
Not urgently, but you should be planning it. The spec ships with a formal deprecation policy carrying a twelve-month minimum window, so nothing breaks overnight: the Roots, Sampling and Logging features, and the older HTTP+SSE transport, are marked Deprecated but remain fully functional during that window. New builds simply shouldn't adopt them going forward.
- **Check your SDK version.** Official SDKs for TypeScript, Python, C#, Rust and Java support the 2026-07-28 revision; if your MCP client or server is pinned to an older SDK release, it's still speaking the session-based protocol.
- **Audit anything relying on server-initiated sampling or roots.** Both are deprecated; the suggested migration is integrating directly with your LLM provider's API instead of `sampling/createMessage`, and passing directories via tool parameters instead of `roots`.
- **If you self-host behind a load balancer, this update is the actual fix, not a nice-to-have.** Sticky-session workarounds (session-affinity cookies, hash-based routing to a specific pod) can be retired once your server and client are both on 2026-07-28.
- **Re-run authorization tests after upgrading**, since `iss` validation is now required client-side and a client that doesn't check it will simply fail closed against a correctly configured 2026-07-28 authorization server, which is the intended behavior, not a bug to route around.
How AIBOOTSTRAPPER helps
This is the exact integration layer we work in on every custom agent build. Leon & Vera, the AI marketing and booking agents we built for local service studios in Europe, is a good example of why this matters in practice: Vera has to reliably connect to WhatsApp, Instagram, Facebook and web chat, plus the studio's existing calendar and booking system, and answer any of them at any moment without losing track of who it's talking to. The challenge going in was that studios were losing trial-session enquiries to slow replies and had no budget for a marketing team; the fix was two connected agents, one producing weekly ad creative and one handling every channel's enquiries and booking the appointment directly, with the owner controlling ad spend from as little as €10 a day and zero manual posting required.
That kind of multi-system reliability is precisely what a stateless, self-describing protocol is built to make easier to scale and harder to get wrong. If you're evaluating whether your next agent's tool integrations should be built as one-off connectors, migrated onto MCP, or something else entirely, see our AI product development services or book a call and we'll scope it against your actual stack, not a generic checklist.
Want this done for you?
Book a free strategy call and we'll show you how to build and market your business with AI.
Sources and further reading
- 1.Model Context Protocol — Key Changes, 2026-07-28 specification changelog (official docs)
- 2.Model Context Protocol Blog — The 2026-07-28 Specification (official announcement)
- 3.VentureBeat — MCP just got its biggest update ever: here's what changes for AI agents
- 4.IETF RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification