Why MCP dropped sessions

The Model Context Protocol spec published on July 28, 2026 is the largest change to MCP since remote servers became common. In the announcement on the MCP blog, lead maintainers David Soria Parra and Den Delimarsky describe MCP as now being "a request/response stateless protocol". The initialize handshake is retired. So is the Mcp-Session-Id header.

If you've run an MCP server behind a load balancer, you already know why. Sessions meant sticky routing, a shared session store, or both. Every request had to land on the instance that remembered the handshake, or that instance had to look the session up in Redis. That was a reasonable design for a local tool talking over stdio. It's an awkward one for an HTTP service that thousands of agents call.

The install base made this a now-or-never decision. The same post says Tier 1 SDKs see "close to half-a-billion downloads a month", and the TypeScript and Python SDKs have each passed 1 billion downloads in total. A breaking change at that scale hurts. Waiting another year would have hurt more.

We have a direct stake here. Custom MCP servers are stage 2 of our AI deployment program, and we maintain the open-source Google Ad Manager MCP server. What follows is how we read the spec and what we're checking on our own servers.

What breaks

The obvious part first. Clients that send initialize and wait for a response, and servers that reject requests without a session ID, both need changes. Anything that keyed a cache, a rate limit or an audit log on Mcp-Session-Id has lost its key, and that tends to be the change people find last.

Then the less obvious parts.

Error codes. As PPC Land points out, the missing-resource error code changes from -32002 to -32602. If your client retries or falls back based on the numeric code, it will now take the wrong branch without any visible failure. Grep your codebase for the literal.

Client registration. Registration shifts from Dynamic Client Registration to Client ID Metadata Documents. If your authorization server only supports DCR, that's a real project, and it usually belongs to a different team from the one running the MCP server. Start that conversation early.

Deprecations. Roots, Sampling and Logging are deprecated, with a minimum 12-month deprecation window. Twelve months is plenty, provided someone files the ticket this quarter. Servers that call back into the client's model through Sampling need a different design. Anything that relied on protocol-level Logging should move to the observability stack you already run (OpenTelemetry, your log pipeline, whatever your platform team supports).

Extensions. The spec adds a formal extensions framework covering Tasks, MCP Apps and Enterprise Managed Authorization. If you built on any of those, read the extension documents rather than assuming the old calls behave as before.

What gets easier

Hosting, mostly. Google's write-up on the stateless updates puts it plainly: any server instance can now handle any request behind a round-robin load balancer. MCP servers can run on Cloud Run or Cloud Functions and scale to zero when nobody's calling them. Google also notes that the GitHub MCP Server adopted the spec and dropped its Redis session storage.

That last detail is worth showing to whoever pays your cloud bill. A session store is a stateful dependency you have to provision, monitor, back up and secure. For a lot of MCP servers it was the only stateful component. Take it away and the server becomes an ordinary HTTP service, which every platform team already knows how to deploy, autoscale and roll back.

The new Mcp-Method and Mcp-Name headers matter for the same reason. With the method and name of each call exposed as headers, a gateway can route, rate-limit and authorize without parsing the JSON-RPC body. You can send write-heavy calls to a separate pool with tighter limits, or block a single tool at the edge during an incident, using ordinary gateway configuration instead of custom middleware.

State the new way

A stateless protocol doesn't make your application stateless. Your ad server, CRM and database are full of state. What changes is where it lives: in your systems, referenced explicitly, instead of implied by a connection.

The pattern we use is simple. When a tool creates something that later calls depend on, it returns an explicit handle in its result (a draft ID, a job ID, a pagination cursor), and the next tool takes that handle as a required argument. Whatever the handle points to lives in your own datastore with an expiry. The model passes the handle back, and any instance can serve the next call because the state sits in the database rather than in process memory.

There's a side effect we like. Explicit handles make agent workflows auditable. A handle in a tool result shows up in the transcript, where a reviewer can follow it. A session variable on the server never did.

Long-running work is the other case. If a report takes four minutes to build, start it, return a job handle, and expose a status tool. Don't hold the HTTP request open and hope the load balancer's idle timeout is generous.

Security after the NSA guidance

In May, the NSA's AI Security Center published security design considerations for MCP. ExecutiveGov's summary highlights serialization risks, trust boundaries and agent misuse, and quotes the guidance saying these "cannot be patched at isolated endpoints."

We agree with that, and the stateless spec makes it more pressing. Once any instance can serve any request and gateways route on headers, your security boundary moves to the gateway and the authorization layer. Treat your MCP estate as one system: an inventory of every server, the tools each one exposes, the credentials each one holds, and which agents can reach which tools.

Ad tech shows why this matters. PPC Land lays out the timeline: Google Ads released a read-only MCP server on October 7, 2025, Amazon Ads opened its beta on February 2, 2026, and Meta launched MCP connectors with write access on April 29, 2026. As of March 11, 2026, all ten entries in IAB Tech Lab's Agent Registry were MCP servers. Read access to campaign data is a reporting risk. Write access to budgets is a financial one.

Our default for any server with write tools: split read and write tools so they can be granted separately, require an explicit confirmation argument on anything that spends money or changes delivery, scope credentials to the smallest account hierarchy that works, and log every write with the calling agent's identity and full arguments. With header routing in place, write calls can also sit behind their own gateway policy.

Migration notes from our own server

Our Google Ad Manager MCP server lets Claude manage campaigns, line items and creatives through natural language. It's Python and MIT licensed, and because it can touch live ad delivery, we treat a spec migration as a production change rather than a dependency bump.

This is the checklist we're working through. It applies to most servers:

  1. Upgrade the SDK and confirm the server answers a request that arrives with no prior initialize.
  2. Remove every dependency on session IDs, including in logging and rate limiting, and replace it with per-request identity from the auth layer.
  3. Search server and client code for a hardcoded -32002, and add a test that expects -32602.
  4. List every use of Roots, Sampling and Logging, and put a replacement date on each one well inside the 12-month window.
  5. Confirm your authorization server supports Client ID Metadata Documents.
  6. Run two instances behind a round-robin balancer in staging and replay a real agent workflow against them.

Step 6 finds most of the problems. Hidden state is rarely where you expect it: an in-memory cache of report results, a lazily created API client holding a token, a pagination cursor kept server-side "just for now".

Test with more than one client as well. Clients will adopt the spec at different speeds, so your server will see old and new behavior side by side for a while. The design principle is the one we used on Promptify, where several LLM providers sit behind one interface: keep the differences between versions inside the integration layer, so the agents and workflows above it never have to know which version of the outside world they're talking to.

If you're planning MCP servers for internal tools and want them on the new spec from the first commit, that's work we take on.

Sources