The Model Context Protocol published its biggest spec revision last week — the 2026-07-28 release candidate — and the most consequential change is one word: stateless.
The session concept is gone. Not deprecated, not discouraged — removed. The initialize/initialized handshake that used to happen at connection time is eliminated. The Mcp-Session-Id header that tied requests to a specific server instance is gone. Any request can now land on any server instance. The protocol no longer knows or cares that this tool call is part of the same work session as the previous one.
This is the right engineering decision. Sessions were a scaling problem: they required sticky routing at the load balancer, shared session stores for horizontal deployments, and careful state management that broke whenever a server instance restarted. Making MCP stateless lets servers run as true serverless functions — no shared state, no sticky routing, plain round-robin load balancing. The infrastructure simplifies dramatically.
But something important disappeared along with the complexity. Sessions weren't just an infrastructure mechanism. They were the natural way to group related work.
What Sessions Actually Did
Before the spec change, when your AI agent connected to an MCP server — a tool that fetches your calendar events, reads your project files, queries your coding history — the session was the container. Requests within the same session were implicitly part of the same work context. The agent checking your calendar, writing code, and committing to git was one session of focused work.
The protocol knew this. Nothing had to track it explicitly because the session header carried it automatically.
That implicit grouping matters more than it might seem. When you're measuring developer productivity with agentic tools, the session is the unit of work. Not the individual tool call, not the individual token, not the individual file write. The session is when you sat down, what you were trying to accomplish, what tools the agent reached for, and when the meaningful work ended. Strip sessions from the protocol and you still have the individual events — but the structure that makes them interpretable as work is gone.
What Fills the Gap
The MCP maintainers know what they removed. The 2026-07-28 spec replaces protocol-level sessions with something more explicit: protocol version, client info, and capabilities now travel in _meta on every request. Servers can track whatever context they need at the application layer. Nothing stops a tool server from maintaining session-like state if the application requires it.
But "nothing stops you" is not the same as "the protocol handles it." The difference matters for measurement. When sessions existed at the protocol layer, every MCP-aware tool automatically produced session-scoped data. Now, any session-equivalent context is opt-in — implemented by individual server authors who may or may not think about it the same way, with the same granularity.
For developers building on top of MCP — or developers who want to understand their own work with AI agents — this moves the problem up the stack. You need something above the protocol layer that groups related tool calls into meaningful work units.
Why This Matters for Agentic Productivity Measurement
The existing approaches to measuring developer productivity with AI tools were already incomplete. Acceptance rate, token count, time to first commit, tasks per day: each captures part of the picture but misses the work session as the natural unit.
The Copilot outage data from earlier this year made this concrete. Teams tracking productivity at the day level saw anomalous low-output days that correlated with service degradation — but only teams with session-level resolution could tell which sessions were disrupted, what type of work those sessions involved, and whether recovery happened within the same day or bled into the next. Day-level aggregation flattened the signal.
The MCP session removal makes a version of this problem permanent for agentic work. If your AI coding agent is making tool calls through MCP servers — reading your project context, querying your git history, fetching external data — those calls are now protocol-level equivalent to calls made by a completely different session. The structure that would let you say "this was a focused three-hour refactor" versus "these were scattered background lookups" has to come from somewhere else.
In practice, somewhere else means the development environment. The application that tracks which windows are open, which editors are active, how much time elapsed between consecutive tool calls. Not the protocol layer, which is no longer in the session business. Not the AI tool itself, which may span multiple sessions and multiple users. The environment-level context that knows when you sat down and what you were doing when the agent made those tool calls.
The Stateless Pattern and What It Gives Up
This is one data point in a broader pattern. The infrastructure for AI coding tools is maturing toward commodity services: stateless, horizontally scalable, interchangeable instances. That's good for reliability. It means the servers connecting your AI agents to your data can run without the operational overhead that stateful architectures require.
The tradeoff is that "work session" becomes a concept the infrastructure consciously declines to track. The protocol optimizes for scale, not for measurement. The tools that connect agents to data optimize for throughput, not attribution.
This is the same tradeoff that REST made relative to stateful protocols. REST won. Stateless scales; stateful doesn't. But you don't need stateful infrastructure to maintain session context — you need something at the application layer that cares about grouping requests into coherent units. For web apps, that's the auth token and the session record in the database. For agentic development workflows, it's the development environment that knows you're in a focused coding session.
The protocol declines to carry this context. Something above it has to.
The Measurement Layer Has to Be Intentional Now
There's a version of this problem that existed before the MCP spec change and was mostly invisible. When sessions existed at the protocol layer, developers got session-scoped data for free from every MCP-connected tool. You could reconstruct a work session by inspecting session IDs across tool call logs, even if nobody built measurement tooling explicitly.
That free data is gone after July 28. If you want session-scoped attribution of agentic work, you have to build it somewhere specific and maintain it deliberately. The MCP spec no longer does it as a side effect.
What this looks like in practice: session context has to live in the tracker, not the protocol. The app session data — which editor was open, what project was active, how long the focused period lasted, which agent tools were invoked in what order — is what lets you say "these MCP calls were part of a three-hour coding session on the auth refactor" rather than "twelve tool calls happened at various times." The session context that the protocol used to carry by default now has to be built and maintained by the layer that cares about it.
For developers who want to understand how their agentic workflows actually spend time, this is the practical implication. The measurement problem didn't go away when the protocol dropped sessions. It just became something you have to solve explicitly instead of inheriting for free.
At xeve, we built an MCP server that exposes user data to Claude Code. When you ask the agent to analyze your coding patterns or correlate your focus sessions with biometric data, those tool calls flow through MCP to our edge functions and back. The stateless spec is welcome news from an infrastructure standpoint — no shared session state to manage, no sticky routing overhead. But it also makes explicit something we'd been handling implicitly: the session that groups those interactions into meaningful work context lives in the tracker, not the protocol.
The MCP team made the right call for the infrastructure. The measurement problem they surfaced is worth solving somewhere.