SKIP TO CONTENT
AI AGENTS6 minAgents in Production / Ep. 11 · Stage 11-1

MCP Without Sessions: Where to Keep Data Between Calls

Your MCP server keeps data in a map keyed by session id. On version 2026-07-28 that id is gone, so where does the data go?

XIN
Pixel-art night scene of a row of identical server cabinets with no luggage beside them. Each glowing envelope arriving on a conveyor carries its own small backpack, and a teal lockbox key hangs from one envelope.

IN 30 SECONDS

Stateless MCP is the change in specification version 2026-07-28 that removes sessions, so each request carries what the server needs to answer it. Whatever your server kept per session needs a new home. This stage sorts where each piece goes.

KEY TAKEAWAYS · 3

  • Version 2026-07-28 removes MCP sessions. Every request carries its protocol version and client capabilities in a _meta field.
  • In my sorting rule, protocol facts go in each request, identity in the access token, mid-call context in sealed state, lasting work behind a handle.
  • clientInfo is self-reported: it never proves who is calling.
On this page

The problem: there is no session to lean on

IN SHORT One quick way to break a server on the new version: a map keyed by session id. There is no session id any more.

Where I stand: I build agent tooling, 200+ agents across about 21 Claude Code plugins. Anything marked as a proposal is my opinion, not the standard.

WORDS TO KNOW

MCP
Model Context Protocol: the open standard for how an AI app (the client) calls tools on a program (the server).
Session
Context a server kept from one request to the next for the same client.
Stateless
The protocol keeps no memory between requests. Your own app can still store data.
Load balancer
The part that spreads requests across several copies (instances) of the same server.

IN PLAIN WORDS

Until now, an MCP Model Context Protocol: the open standard for how an AI app (the client) calls tools on a program (the server). See the glossary client opened a Session Context a server kept from one request to the next for the same client. See the glossary once, and the server could hang data off it.

Version 2026-07-28 of the spec removed sessions, so the protocol is now Stateless The protocol keeps no memory between requests. Your own app can still store data. See the glossary. Each request must stand on its own. A Load balancer The part that spreads requests across several copies (instances) of the same server. See the glossary may send two calls from one client to two different instances.

This post comes out the day AGNTCon + MCPCon North America ends in San Jose (22 and 23 October). I expect a lot of these migrations to get argued about there.

What changed for servers in MCP 2026-07-28

IN SHORT Much of what the session held now rides on every request: version, capabilities, log level.

The changelog opens with two lines: “Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport.” Then: “Make MCP stateless: remove the initialize/notifications/initialized handshake.”

THE SAME CALL, BEFORE AND AFTER

Up to 2025-11-25

  • The client says hello once (the initialize handshake) and may get a session id.
  • The server keeps a map from that id to whatever it needs.

From 2026-07-28

  • No hello and no session id.
  • Each request carries what it needs, so any instance can answer it.
Simplified from the specification changelog.

Those facts ride in a field called _meta, where the protocol version and the client capabilities are required. The client’s name, the log level and trace context are optional. Over HTTP, a request missing a required field gets error -32602 and HTTP 400.

ADAM says: Think of a cloakroom: any attendant can serve you, as long as you bring your ticket. Where it breaks: in my design, the server also checks that the ticket is yours.

A server that only speaks the new version should ignore a stray Mcp-Session-Id. It should never mint or echo one, and should answer GET or DELETE with 405.

Coming up next: So where does the rest of your session data go?

Where each piece of session data goes

IN SHORT The protocol is stateless, but your server doesn’t have to be: its state just can’t live in the connection any more.

The spec’s Statelessness section says servers “MUST NOT rely on prior requests over the same connection to establish context”. State that spans requests has its own rule:

“MUST be referenced by an explicit identifier the client passes on each request.”

MCP specification 2026-07-28, Statelessness

That covers The local transport: the client starts the server as a process and talks to it through standard input and output. too: an open connection “is not a conversation or session”.

WHERE IT GOES

Decide: This used to live in the session. Where does it go now?Decision tree: This used to live in the session. Where does it go now? If It describes the caller’s protocol: version, capabilities, log level, trace, then Read it from each request. If It’s who the caller is, then Take it from the access token. If It’s the middle of one call, waiting on user input, then Seal it into state the client sends back. If It must outlive a call: an import, a draft, a job, then A handle over your store.DECIDEThis used to live in thesession. Where does it gonow?If it describes thecaller’s protocol: version,capabilities, log level,traceRead it from eachrequestIf it’s who the caller isTake it from theaccess tokenNever from the client’sself-reported nameIf it’s the middle of onecall, waiting on user inputSeal it into statethe client sends backShort expiry, bound tocaller and requestIf it must outlive a call:an import, a draft, a jobA handle over yourstore
The _meta keys: io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities (required), io.modelcontextprotocol/clientInfo and io.modelcontextprotocol/logLevel (optional), plus traceparent. The spec calls this optional state requestState.

Step 1. The question. Take one field your server kept per session.

Pick a step to see it move
  1. The question Take one field your server kept per session.
  2. Protocol facts Read them from _meta on every request, never from an earlier one.
  3. Identity It comes from the access token, each time. clientInfo is self-reported and “SHOULD NOT” drive security decisions.
  4. Mid-call context It goes into sealed state the client sends back on its retry. Binding it to the caller, an expiry and the request limits replay, but doesn’t make it single-use.
  5. Lasting work It stays in your own store, behind a handle: an id the server mints.
My sorting rule, built on the spec’s requirements: four kinds of session data, four new homes.

One caveat: the spec makes authorization OPTIONAL. Taking identity from the token assumes an HTTP server that authenticates each call. I’d want that on any server that touches real data.

ITEM GET

Session data gets a new home

Each piece of session data gets a new home: the request, the token, sealed state or a handle.

Sources: 2026-07-28 release, changelog, base protocol, Streamable HTTP, all read on 7 October 2026.

FAQ

Servers “MUST implement” server/discover, which lists their versions and capabilities. List results such as tools/list carry two required fields, ttlMs and cacheScope, and “no longer vary per-connection”. ping is gone, and every result carries a resultType.

STAGE CLEAR

What you now know

  • Why a map keyed by session id breaks: the id is gone, and the next call may reach another instance.
  • Where each kind of session data goes now, and why identity comes from the token.

Check yourself

Tap or click a question to see the answer.

Over HTTP, a second request on the same connection has no client capabilities in its _meta. Can the server reuse the first request’s?

No. They are required on every request, so this one gets -32602 and HTTP 400.

Next stage:How does a server with no session ask the user for input in the middle of a call?6 min
Adam Boudjemaa
Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.