The July 2026 MCP spec update introduces a stateless core, an extensions framework, In March 2025 I wrote a post titled No, MCPs Have Not Won (Yet). I wrote it in response to usability and implementation gaps I hit while trying to integrate MCP into AutoGen - an agent framework I was building heavily at the time. The reference MCP servers at the time were limited, the documentation assumed servers running in Claude Desktop or similar, and the moment I tried to bundle everything into a real, deployed agent, there were clear friction points.MCP has changed between then and now.In particular, fast forward to July 28, 2026, there’s a fifth revision of the spec - this post reviews the key updates.TL;DRThe key updates in the 2026-07-28 spec:Stateless core. MCP servers are now ordinary HTTP services - any request can hit any instance, so you can load-balance, scale, and run them serverless without sticky sessions. The initialize handshake and protocol-level sessions are gone; every request carries its own version and capabilities.Extensions framework. A thin core plus optional, opt-in extensions, each negotiated per request and governed by a proposal process. Three are official today: Tasks, MCP Apps, and Enterprise-Managed Authorization.Tasks. A first-class extension for long-running work: the server returns a durable handle and the client polls, instead of holding a connection open.Multi Round-Trip Requests (MRTR). Mid-call input, like asking the user to confirm something during a tool call, without keeping a connection open.Auth hardening. A proper OAuth resource-server model, and a move away from dynamic client registration.Deprecations. Sampling, Roots, Logging, and the legacy HTTP+SSE transport are on a deprecation path.SDK Parity. Today only the C# sdk have all updates implemented with others in progress.This post is builds on concepts from the Designing Multi-Agent Systems book. Chapter 12 covers MCP and agent communication in more depth, with complete implementation code.The 2025 protocol opened every connection with an initialize handshake and carried a session, identified by an Mcp-Session-Id header. Because that session lived on one instance, every request in a conversation had to be routed back to it (sticky routing). A side effect of this this is that you could not spread traffic freely across a pool of servers. A restart could lose the session state, and both ends carried the complexity of setting it up and tearing it down. A call looked like this:POST /mcp