MCP's Stateless Core Just Shipped: What a Deploy-From-Chat MCP Server Gets to Delete

Three days ago, on July 28, 2026, the Model Context Protocol dropped the Mcp-Session-Id header and the initialize handshake that every remote MCP server has been built around since the protocol launched. That single removal is the reason a self-hosted MCP server — the kind that takes "deploy this repo" from an agent and turns it into a running HTTPS service — can now sit behind a plain round-robin load balancer with no sticky routing rule and no shared session store keeping instances in sync. This is the concrete architecture change, and what it means for a platform deciding whether to pin its own MCP server to this exact spec version.

The Session Is Gone, and So Is the Infrastructure Built to Route Around It​

Under the pre-2026-07-28 transport, a client's first request performed an initialize handshake, and whichever server instance answered it got handed an Mcp-Session-Id that pinned every subsequent request from that client to that same instance. Two things followed from that, and both were operational tax:

• Sticky routing at the gateway. The load balancer had to inspect the session header and route on it, not just round-robin across healthy instances — a gateway rule that plain HTTP infrastructure doesn't give you for free.
• A shared session store. If an instance died or got recycled mid-session, the client's session state had to live somewhere else — a Redis-backed store, typically — or the client simply broke and had to re-handshake from scratch.

The 2026-07-28 specification, which the Model Context Protocol project locked as a release candidate on May 21 and finalized after a ten-week validation window on July 28, removes both requirements at the protocol level. Protocol version, client info, and capabilities now travel inline in a _meta field on every request instead of being negotiated once and remembered server-side. Any request can land on any instance, because there's no server-side state a specific instance is uniquely holding. That's not a performance optimization layered on top of the old transport — it's the old transport's reason for sticky sessions ceasing to exist.

What Actually Changed, Beyond "No More Sessions"​

The stateless core is the headline, but the July 28 spec is — by the Model Context Protocol project's own description — the largest revision since the protocol launched, and three other changes matter for a server operator:

• Header-based routing. Streamable HTTP requests now carry Mcp-Method and Mcp-Name headers, so a gateway can route and authorize on the method and tool name directly, without deep packet inspection into the JSON-RPC body.
• Cacheable list responses. tools/list, prompts/list, resources/list, and resources/read responses now carry a ttlMs freshness hint and a cacheScope (public or private). A client can cache a tool list for as long as the server says it's valid instead of re-fetching it on every connection.
• A formal feature lifecycle policy. Every feature is now Active, Deprecated, or Removed, with a minimum twelve-month window from the revision where it's first marked Deprecated to when it can be removed — shortened to a ninety-day floor only for a feature carrying a published security advisory or documented active exploitation. Roots, Sampling, and Logging are the first three features deprecated under this policy: they still work today, and by the policy's own floor they're guaranteed to keep working for at least twelve months from July 28, 2026.

Two extensions also moved out of the experimental core into formally versioned add-ons: MCP Apps, which lets a server ship a sandboxed-iframe UI a host can prefetch and security-review before rendering, and Tasks, which replaces "hold the HTTP connection open" with a poll-based tasks/get and tasks/update for work that runs longer than one request. Neither is what makes the stateless-core change interesting for a platform's own MCP server, but both are why the project is calling this a rewrite rather than a patch.

The Before/After for a Deploy-From-Chat MCP Server​

This is where it stops being abstract. Bex's own /mcp server is the concrete case: an agent calls deploy with a repo and a bex.yml, gets back a service, and polls get_service until status.phase reads Running — plus, per bex's rollback documentation, a rollback that restores a previous successful deploy's exact image as a fresh deploy, available over the API and MCP today. None of those calls carry any inherent reason to land on the same server instance twice in a row; the state that matters — what phase a deploy is in, which image a rollback should restore — lives in bex's own datastore, not in protocol-level session memory. That makes it close to the textbook case the stateless core was designed for, and it's exactly the gap between what the old transport required and what the state genuinely needed:

The row worth sitting with is cross-call state, because dropping the protocol session doesn't mean an MCP server gets to stop tracking anything — it means the tracking moves from implicit transport state to an explicit value the model carries. Bex's deploy tool already returns a service identifier the agent uses on every follow-up get_service call; that pattern was already the right shape before July 28, and the spec change just deletes the redundant, hidden session tracking that used to run alongside it. A server built the old way — leaning on session affinity to remember which deploy an agent was polling — has real migration work under this spec: move that state into an explicit handle, because the transport will no longer hold it for free.

What Pinning to This Version Actually Buys You​

A server operator has two options once a spec revision finalizes: pin to it explicitly, or keep tracking whatever the draft says this week. The case for pinning here isn't "newer is better" — it's that this specific revision ships with a lifecycle guarantee the previous one didn't have.

Before the July 28 spec, there was no formal deprecation policy at all; a feature could be quietly dropped between revisions with whatever notice the maintainers chose to give. Now, pinning a production server to 2026-07-28 comes with three concrete guarantees, not just a version string:

1. A twelve-month floor on anything marked Deprecated. If a future revision deprecates a feature bex's server depends on, that feature is contractually still working for at least a year from the revision that deprecates it — enough runway to plan a migration on a schedule, not a fire drill.
2. A ninety-day carve-out, and only for security. The floor can only compress to ninety days for a feature with a published advisory or documented exploitation — which means a shorter deprecation window is itself a signal worth alerting on, not routine noise to filter out.
3. A known set of already-deprecated features to avoid building on. Roots, Sampling, and Logging are deprecated as of this revision. A server built against 2026-07-28 starting today knows not to invest in those three — that's information a server pinned to an earlier, pre-lifecycle-policy revision simply didn't have, because there was no deprecation list to consult.

Compare that to building against the draft that preceded this RC: every one of those guarantees was provisional, because nothing was locked yet. A server team tracking the moving spec through its ten-week validation window was building against something that could still change shape before July 28 — useful for getting ready, but not a foundation to ship production infrastructure on. Now that the window has closed, pinning is strictly better than continuing to track: the guarantees exist, and they didn't before.

The version negotiation itself is cheap to support on both sides of that pin. A server can declare 2026-07-28 and still serve older clients that negotiate down to a prior revision, so pinning the target version for new development doesn't mean an immediate breaking change for a live agent still connected on the previous handshake-based transport — it means new instances stop paying for the sticky-routing and session-store tax the moment the pin takes effect, while the negotiation layer covers the tail of clients still catching up.

What This Actually Deletes From a Production Deploy List​

Put concretely, a platform that pins its deploy/rollback MCP server to 2026-07-28 gets to remove two specific pieces of infrastructure that a stateful MCP transport required and a stateless one doesn't:

• The gateway's sticky-session routing rule keyed on Mcp-Session-Id — replaced by a Mcp-Method/Mcp-Name-aware round-robin rule that doesn't need to remember which instance handled a client's first request.
• The shared session store (Redis or equivalent) that existed solely to survive an instance recycling mid-conversation — not needed, because there's no protocol-level session to lose.

Neither of those was ever bex-specific infrastructure; they were the tax every remote MCP server paid to support a stateful handshake, regardless of what the server actually did once a request arrived. That's the part worth generalizing past this one example: any team running a self-hosted MCP server behind more than one instance had this exact line item on their infrastructure list three days ago, and doesn't anymore.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server built for exactly this kind of agent-driven deploy and rollback. Star the repo on GitHub or deploy your first app today.