What changed on July 28
The Model Context Protocol published its 2026-07-28 specification, and the changelog reads like a rewrite of the protocol's operational model. The headline change, SEP-2567, removes protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. Servers that need cross-call state now use explicit, server-minted handles passed as ordinary tool arguments. The practical effect is stated plainly in the release notes: any MCP request can land on any server instance, and the sticky routing and shared session stores that earlier versions required are no longer needed to keep a conversation coherent.
That single change cascades through the rest of the spec. SEP-2575 removes the initialize and notifications/initialized handshake entirely, making MCP stateless end to end. Every request now carries its protocol version and client capabilities inside _meta, and a new server/discover RPC lets clients negotiate versions up front. Version mismatches return an UnsupportedProtocolVersionError. For anyone who has operated an MCP fleet behind a load balancer, this is the change that removes a whole category of infrastructure pain that had nothing to do with the actual model calls.
Why stateless matters for operators
Sessions are expensive to run at scale. A stateful protocol forces sticky routing so that follow-up requests reach the same instance, and it forces a shared session store when instances come and go. Both are the kind of infrastructure that looks trivial in a demo and turns into an on-call burden in production, especially when autoscaling churns instances underneath a live conversation. By moving state into explicit handles that travel with the request, the new spec lets a plain round-robin load balancer sit in front of a pool of stateless MCP servers. The changelog even standardizes Mcp-Method and Mcp-Name routing headers to support exactly that topology.
The upgrade also adds real caching machinery. A new CacheableResult interface requires ttlMs and cacheScope fields on list and read responses, so clients and shared intermediaries can cache tool and resource listings instead of re-fetching them on every turn. Servers are asked to return tools in a deterministic order to improve prompt-cache hit rates. For a platform team, these are the unglamorous primitives that decide whether an agent backend costs a fortune to run or scales like an ordinary stateless web service. This release moves MCP firmly toward the latter.
Server-initiated requests get reworked
The second structural change, SEP-2322, retires the pattern where a server initiates its own requests back to the client, such as roots/list, sampling/createMessage, or elicitation/create. Those flows assumed a persistent bidirectional stream, which is precisely what a stateless transport cannot promise. In their place the spec introduces the Multi Round-Trip Requests pattern. A server that needs more information returns an InputRequiredResult carrying its inputRequests, and the client answers by retrying the original request with inputResponses attached. All results now carry a required resultType field, complete or input_required, so clients can tell an interim result from a final one.
This is a meaningful redesign for anyone who built against server-initiated flows. The spec also removes SSE stream resumability and message redelivery, so a broken response stream loses the in-flight request and the client must re-issue it with a new request ID. Teams that leaned on long-lived streams for progress and elicitation will need to rework those paths around retries and idempotency. The migration window is generous, but the direction is set, and the sooner integrations assume a stateless, retry-friendly world, the less painful the eventual cutover will be.
Roots, sampling, and logging are on the clock
SEP-2577 deprecates three long-standing features: Roots, Sampling, and Logging. They remain fully functional during the deprecation window, and new implementations should stop adopting them. The suggested migrations are specific. Pass directories or files through tool parameters, resource URIs, or server configuration instead of Roots. Integrate directly with LLM provider APIs instead of relying on Sampling, which asked the client to make model calls on the server's behalf. And send diagnostics to stderr or emit OpenTelemetry data instead of using protocol-level Logging. Each deprecation trims a piece of surface that made MCP harder to reason about and secure.
The Sampling deprecation is the one worth flagging to architects. Server-driven sampling let an MCP server borrow the client's model access, a capability that always sat awkwardly with least-privilege thinking. Pointing servers at their own provider APIs makes the trust and cost boundaries explicit, which is the right default for anything running in an enterprise. Crucially, all of this now happens under a formal feature-lifecycle policy, SEP-2596, that defines Active, Deprecated, and Removed states and guarantees a minimum twelve-month window before removal. Predictable deprecation is exactly what a maturing protocol owes the teams building on it.
Observability moves to OpenTelemetry
The logging change is part of a broader bet on standard observability. The spec now documents OpenTelemetry trace-context propagation conventions, standardizing the traceparent, tracestate, and baggage keys inside _meta so a trace can flow across MCP boundaries. That lets an operator follow a single trace from the agent's decision through the tool call, into the MCP server, down to the database query and the infrastructure underneath. For teams that have watched AI observability fragment into a dozen bespoke log formats, adopting W3C trace context is the move that lets MCP data land in the same tools they already run for everything else.
This matters because agents make tool calls on their own, and when one of those calls is slow or wrong, the engineer debugging it needs a continuous trace rather than a stack of disconnected logs. Emitting OpenTelemetry instead of a protocol-specific log format means an MCP server hands its telemetry to the observability stack built to handle it. For the leaders in our audience trying to move agents from pilot to production, that is not a cosmetic detail, because you cannot operate what you cannot trace, and this release finally gives MCP a first-class answer for tracing.
What it means for your agent roadmap
This is a release candidate, and deprecated features keep working through at least a twelve-month window, so nobody has to scramble. The right response is to read the changelog against your own integrations and sort the work into two buckets. First, the operational wins you can bank soon: stateless servers behind ordinary load balancers, response caching via ttlMs, and OpenTelemetry tracing across your agent stack. Second, the migrations you must plan: moving off Sampling, Roots, and protocol-level Logging, and reworking any flow that depended on server-initiated requests or resumable SSE streams.
The strategic read is that MCP is growing up into infrastructure. The 2026-07-28 spec trades early flexibility for the boring properties that production systems require, namely statelessness, cacheability, predictable deprecation, and standard tracing. For platform teams standardizing on MCP as the connective tissue between agents and enterprise systems, that trade is the one you want, because it makes the protocol behave like the rest of your cloud-native stack. Start the migration planning now, while the deprecation clock is still generous and the cutover is still cheap.
