MCP is going stateless: What the new spec means for AI agents

The Model Context Protocol has had a fast eighteen months. Since Anthropic open-sourced it in late 2024, it has gone from a spec nobody had heard of to the most widely adopted protocol for connecting AI agents to external tools, APIs, and data sources, with over 150 organizations building on it and native support across three major cloud platforms.

On July 28, the MCP project releases the most significant revision to the MCP specification since launch, and the headline change is one that teams running MCP in production have been waiting for: the session model is gone. MCP is going stateless.

If you are building agents that connect through MCP clients, building MCP servers, or both, here is what changes, why the old model was a headache in production, and what MCP replacing its proprietary logging channel with OpenTelemetry means for observability.

Why MCP's session model was a problem in production

Under the current spec, every MCP connection begins with a handshake. The client sends initialize, the server mints an Mcp-Session-Id, and that ID is expected on every subsequent request. For single-instance deployments, this is fine. For anything running at scale behind a load balancer, it quietly introduces one of the more frustrating failure modes in recent protocol history.

Imagine a scenario where your agent sends an initialize request. Your load balancer routes it to Pod A which handles the handshake, stores the session state in its local memory, and mints a Session-Id. When the next request comes, the load balancer may route it to the next available instance, let’s say, Pod B. The load balancer passes the Session-Id with the request but Pod B has no record of that session. This is because pods are isolated containers, each with their own memory space and the session state in this case lives in Pod A's memory, not Pod B's. Pod B receives a Session-Id it has never seen, has nothing to map it to, and returns a 404. No useful error, no indication of what actually went wrong…

Now one of the workarounds for this is sticky sessions: pin each client to the same server instance for the lifetime of its connection, add session-aware load balancers, provision a shared session store, and carefully drain sessions around every deploy. Which means Redis. Which means the protocol designed to simplify AI integrations has quietly become a reason your infrastructure is more complicated than it needs to be.

The new spec eliminates all of that. The following diagram below shows the difference side by side. 

One note worth flagging is that the stateless shift is primarily consequential for remote server deployments. Most local tooling and desktop integrations are largely unaffected by this change, since there is no load balancer in the picture. 

How the stateless core Changes Agent Development

For developers building agents that connect to MCP servers, the headline effect is simple: remote MCP servers now behave like any other stateless HTTP service. With the Mcp-Session-Id and the initialize handshake gone, each request carries what the server needs e.g., protocol version, client identity, capabilities, in a _meta object. Furthermore, session affinity is no longer something your infrastructure has to think about. Any server instance can handle any request. The trade-off is slightly larger request payloads, since capabilities that were transmitted once per session now travel on every call. For most workloads that is an acceptable cost, but it is worth benchmarking against your actual request volumes rather than assuming it is negligible.

Besides session affinity, a couple of other changes in the new spec are worth noting:

• Header-level routing:
  The MCP SDK now automatically adds two new headers to every Streamable HTTP request: an Mcp-Method (e.g., tools/call, resources/read, or prompts/get) and a Mcp-Name, that carries the name of the specific resource or tool being invoked. These let gateways and load balancers route MCP traffic and apply policies at the header level, without having to parse JSON-RPC request bodies. Rate limiting a specific tool, routing expensive calls to dedicated backends, applying per-tool authorization, all can be configured at the infrastructure layer, but how you use them is yours to design.
• State without sessions: 
  For servers that need to track context across multiple tool calls such as a browser session, an ongoing file editing workflow, a multi-step process, the server now returns a reference ID from the tool call that the agent passes back as an argument on subsequent calls. Instead of state hiding in server memory where nobody can inspect it, it now lives in the payload: visible to the model, auditable in logs, and actually debuggable when something goes wrong at 2am. The model can also reason about the handle, which opens up agent behaviours that implicit session state made difficult.
• Multi-step requests:
  The current spec lets servers initiate callbacks to the client mid-tool-call, such as sampling to request an LLM completion or elicitation to ask the user something. Both patterns are deprecated. Their replacement is Multi Round-Trip Requests (MRTR). When a server needs additional input, it returns an InputRequiredResult with an opaque requestState and a description of what it needs. The agent resubmits the call with responses attached. All state travels in the payload, making every interaction explicit and fully auditable. 

Building and deploying MCP servers under the new spec

For MCP server developers, the stateless change is the biggest operational shift the protocol has seen, and honestly it is long overdue.

Without session state to manage, a remote MCP server is now a stateless HTTP service and can be deployed as one. Round-robin load balancing, auto-scaling, serverless containers, all of it works without instance coordination. No session store to provision, no drainage to manage on deploy, no risk of a client landing on the wrong pod. More significantly, global deployment is now viable. Because every request carries its own context, you can distribute MCP servers across multiple regions behind a global load balancer and any instance, anywhere, can handle any request. 

This release also graduates two extensions to official status and standardises authorization across the board.

• Tasks (now official): tools/call can return a task handle instead of an immediate result, with the client managing the lifecycle through tasks/get, tasks/update, and tasks/cancel. No socket is held open for the duration. This is the right pattern for tool calls that kick off work lasting more than a few seconds such as file processing, code generation pipelines, batch operations, and it fits naturally with the stateless model since there is no long-lived connection to keep alive.
• MCP Apps (now official): servers can deliver interactive HTML interfaces rendered by hosts in sandboxed iframes. Yes, that is UI in a protocol spec. Tools declare their UI templates in advance for host security review, and every user action routes through the standard JSON-RPC audit path. 
• Authorization: Authorization in the new spec aligns with OAuth 2.1 and OpenID Connect, including iss parameter validation and Resource Indicators for scoped token delegation. The enterprise-managed authorization extension lets organizations control MCP server access centrally using the Identity Assertion JWT Authorization Grant, with a full audit trail of which agent called which tool on whose behalf.

What the move to OpenTelemetry means for observability

This is the change that matters most for anyone trying to understand what their agents are actually doing in production.

Until now, MCP had its own proprietary logging channel for sending structured messages from MCP servers to clients. It worked well enough during development but it is a dead end in production because those logs lived in their own silo. You could not correlate them with what was happening in the rest of your application. If an agent's tool call failed or slowed down, you were piecing together what happened across two separate places with no way to connect the dots.

The new spec replaces that proprietary channel with OpenTelemetry. If you are not familiar with OpenTelemetry, it is the industry standard for collecting and exporting observability data e.g., traces, metrics, and logs, across any technology stack. Any service or tool that emits OTel data can be monitored in the same place, correlated against the same timeline, and debugged with the same tooling.

What makes this particularly powerful for MCP is that the new spec also formally standardises how requests are tracked as they move through different systems using W3C Trace Context. Think of it like a tracking number on a package. When your agent makes a tool call, that call might touch your MCP server, which calls an external API, which calls a database. W3C Trace Context is what lets you see all of that as a single connected trace in any OTel-compatible backend making every tool call made by your agents proper observable events. 

New Relic has been OTel-native from the start, which means MCP servers moving to OpenTelemetry slot directly into the same New Relic tooling you already use for the rest of your stack. New Relic also has native MCP monitoring in its AI Monitoring platform. If you are new to OpenTelemetry and want to understand how to get started with New Relic, the New Relic OpenTelemetry documentation is the right place to start.

What’s next

This architectural shift will allow developers to operate a much simpler and more scalable stack. Find the release candidate and full spec text at modelcontextprotocol.io and it's worth testing your implementations against. Check out the full announcement and SEP index here.

A simpler architecture does not mean less to monitor. Agentic systems fail in subtle ways, and knowing which tool call is slow, which downstream service is quietly degrading, or which agent is behaving unexpectedly in production matters just as much as how you deploy. New Relic is actively expanding MCP monitoring across more language runtimes as the ecosystem moves toward OTel-first telemetry, with the goal of giving you complete visibility into how your agents behave in production, right alongside everything else in your stack.