· 12 min read

MCP Just Ripped Out Its Own Session Model. The 2026-07-28 Spec Is a Breaking Change Dressed Up as a Point Release

Stack Tools AI

MCP just turned the initialize/initialized handshake (the thing every MCP server and client has opened a connection with since the protocol launched) into a deprecated relic. The 2026-07-28 specification, pushed live yesterday by the Agentic AI Foundation's maintainers, retires session state from the protocol core entirely. No Mcp-Session-Id. No handshake. Every request now carries its own protocol version, client identity, and capabilities, and three new headers become mandatory on every call. This is versioned like a date-stamped point release. It behaves like a major-version break.

I run four MCP servers across two client projects, and I spent Monday morning reading the changelog instead of shipping. That's the actual cost of this release for a one-person shop: not the migration itself, which the maintainers made reasonably graceful, but the hour you lose figuring out whether you're affected at all.

What actually changed

The core move is dropping protocol-level sessions. Under the old spec, a client opened a connection, ran initialize, got back an Mcp-Session-Id, and every subsequent call carried that header, pinning the client to whatever server instance issued it. Under 2026-07-28, that handshake is gone. Every JSON-RPC request is self-contained, carrying protocol version and client identity in a _meta object. If a client wants to know a server's capabilities up front, it calls the new server/discover RPC, but that's optional, not a gate you have to pass through before doing real work.

Two headers become required on Streamable HTTP requests: Mcp-Method and Mcp-Name, so gateways and load balancers can route and rate-limit on the operation without parsing the JSON body. A third, MCP-Protocol-Version, tells the receiving server which spec revision the request was written against. According to the official spec blog, this work traces back through six Specification Enhancement Proposals: SEP-2575 and SEP-2567 for the handshake removal, SEP-2243 for header-based routing, SEP-2549 for cacheable list responses, SEP-2663 for the redesigned Tasks extension, and SEP-2577 for the deprecation list.

Two features also graduated out of experimental status in this release: MCP Apps, which lets a server declare interactive HTML that renders in a sandboxed iframe inside the chat instead of dumping raw JSON at the client, and Tasks, a formal async pattern with tasks/get polling and tasks/update for mid-flight input, replacing whatever ad-hoc long-running-job workaround your server was probably already hand-rolling.

If you need to carry state across calls now, the pattern the maintainers recommend is an explicit handle: a tool call returns something like basket_id: "bsk_8f3a", and the model passes that handle back as a normal argument on the next call. It's uglier on the wire than an implicit session, but it's visible to the model, which turns out to matter for reasoning about multi-step tool use.

Why stateless is the right infra for one person

The pitch from the maintainers is enterprise-flavored (sticky sessions and shared session stores are annoying at Kubernetes-cluster scale), but the actual beneficiary of statelessness is whoever has the least infrastructure to spare. A solo operator running an MCP server on a $6/month Hetzner box, a Cloudflare Worker, or a Vercel function was already fighting the old spec's assumptions. Sticky sessions on serverless mean either paying for a warm instance you don't need or building session affinity logic that a five-person infra team would consider a Tuesday. Under the new core, any compatible instance can answer any request, so you can put your MCP server behind whatever load balancer or edge function you were already using for the rest of your stack, no special-casing required.

Cloudflare said as much in its announcement quote: its Agents SDK supports the new spec from day zero because it lets MCP servers run in Workers without the transport-session overhead that used to force sticky routing. That's not an enterprise convenience. That's the deployment shape most solo operators already have for everything else they run.

The governance shift nobody's tracking

MCP isn't Anthropic's protocol anymore in any formal sense, and hasn't been since December 9, 2025, when it became a founding project of the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, OpenAI, and Block, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. That structure is why this release reads like a standards-committee document instead of a vendor blog post: formal SEP numbers, a public deprecation registry, a twelve-month clock on every removed feature. The 2026-07-28 blog post carries quotes from Anthropic, OpenAI-adjacent partners, AWS, Google Cloud, Microsoft, Cloudflare, and Netlify, all committing to day-one support. When six competing infrastructure vendors agree to ship the same breaking change on the same day, that's not a feature announcement, that's a protocol behaving like it expects to still be here in five years.

The download numbers back up why they can move like this: the maintainers report close to half a billion downloads a month across the Tier 1 SDKs now, with the TypeScript and Python SDKs each individually past a billion downloads total. That's up from the 97 million monthly figure this blog covered back in March. MCP isn't a bet anymore. It's infrastructure with a governance body that can afford to break things on a schedule, because it's confident everyone will follow.

The twelve-month clock and what's actually deprecated

Nothing breaks today. Roots, Sampling, Logging, HTTP+SSE transport, and Dynamic Client Registration are all marked deprecated as of July 28, 2026, and per the formal deprecation policy (SEP-2596), they're guaranteed to keep working for at least twelve months: earliest removal date July 28, 2027. Roots gets replaced by passing paths as ordinary tool arguments. Sampling, where a server called back into the client's LLM, goes away in favor of servers hitting LLM provider APIs directly, which closes a trust-boundary problem that never sat well with anyone doing a security review. Logging moves to stderr or OpenTelemetry. Dynamic Client Registration gets replaced by Client ID Metadata Documents, though DCR keeps functioning for now.

Authorization tightened too, even where nothing's deprecated: authorization servers must now return the iss parameter per RFC 9207, and clients must validate it before redeeming a code, closing an authorization-server mix-up hole. If a CLI or desktop MCP client of yours has ever thrown a mysterious redirect_uri error during OAuth, that's the DCR application_type gap this release closes.

What I'd actually do

Don't touch anything this weekend. That's the honest first instruction, and it's also the one most "breaking change!" posts skip because urgency drives clicks. You have a twelve-month floor on every deprecated feature, and the new spec version is additive at the transport level: a well-behaved client or server negotiates protocol version and falls back gracefully.

What you should do in the next two weeks: pull up every MCP server and client you maintain and sort them into two piles. Pile one is anything running on a maintained SDK: TypeScript, Python, Go, or C# from the official repos, or a framework like FastMCP. Those absorb this transparently on your next pip install --upgrade or npm update, because the SDK maintainers already did the work; FastMCP's team specifically called out a same-day 4.0 release with background tasks and stateless interactivity built in. Pile two is anything you hand-rolled against the raw JSON-RPC wire format, or anything depending on Mcp-Session-Id for state you never migrated to explicit handles. That pile gets an actual ticket with an actual date, not a someday-maybe.

Here's the honest counter-take: if every MCP server you run is a thin wrapper generated from an SDK template (which describes most solo operators I know, since almost nobody is writing raw JSON-RPC by hand in 2026), this whole release is genuinely a non-event for you operationally. You bump a dependency version, you read the changelog once, you move on. The people who need to actually schedule a migration are the ones who built custom gateways, wrote their own session storage layer for multi-instance deployments, or are running an MCP client embedded in a product where you don't control the SDK version. If that's not you, the honest move is to note the twelve-month deadline in whatever you use for reminders and get back to shipping. The lesson that generalizes past this specific release is the one worth keeping: when a protocol's handshake and header format change underneath you, that's a dependency with a version number, and dependencies with version numbers go on a calendar, not into a weekend panic.

Author

Lukas

Sources

More Stack articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts