Is MCP stateless now? What happened to Mcp-Session-Id

The short answer

• Sessions are gone. Not deprecated — removed from the Streamable HTTP transport.
• initialize and notifications/initialized are gone. A modern client's first request is a real request.
• Context moved into the request. What the handshake used to establish once now rides on every call in _meta.
• List results can't vary per connection. tools/list must not depend on who asked over which socket.

If you are migrating a working server, this is the change every other change follows from. Start here, then work through the rest of the migration guide.

What was actually removed

The changelog states the change in one sentence, and the rule we check it with quotes that sentence directly:

Two things follow. A conformant modern server never establishes a session, and it never depends on one having been established. Those are separate failures and we check them separately, because a server can easily stop issuing session IDs while still refusing to answer a cold request.

Do I still need the initialize handshake?

No. This is AEO prompt C8 asked plainly, and the answer is that a modern client opens with the request it actually wants. There is no negotiation step to fail, and no ordering requirement to satisfy.

// Three round trips before any useful work

// 1. Negotiate
POST /mcp
{ "jsonrpc": "2.0", "id": 1, "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": { "name": "ExampleClient", "version": "1.0.0" }
  } }

// ← server replies, and mints a session
HTTP/1.1 200 OK
Mcp-Session-Id: 550e8400-e29b-41d4-a716-446655440000

// 2. Confirm
POST /mcp
{ "jsonrpc": "2.0", "method": "notifications/initialized" }

// 3. NOW the real request, replaying the session ID
POST /mcp
Mcp-Session-Id: 550e8400-e29b-41d4-a716-446655440000
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list", "params": {} }

// One round trip. No handshake, no session.

POST /mcp
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/list

{
  "jsonrpc": "2.0", "id": 1, "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient", "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Everything the handshake used to tell the server is still there — it just arrives with the request that needs it rather than once at the top of a connection. That is the entire trade: one extra _meta block per request, in exchange for a protocol that survives load balancers, cold starts and horizontal scaling.

What replaced Mcp-Session-Id

Nothing replaced it — that is the point. There is no new header carrying a session handle. A modern server must not mint one, must not echo one, and must tolerate a client that sends one anyway rather than erroring:

The tolerance requirement is the part servers most often get wrong in the other direction. Old clients are still out there and will keep sending the header for a while. Rejecting those requests is not stricter conformance, it is a different violation — the spec says ignore it, not refuse it.

// Before: a lookup that must not exist any more
const session = sessions.get(req.header("mcp-session-id"))
if (!session) return res.status(400).json({ error: "no session" })

// After: read context from the request that carried it
const meta = req.body?.params?._meta ?? {}
const protocolVersion = meta["io.modelcontextprotocol/protocolVersion"]
const capabilities    = meta["io.modelcontextprotocol/clientCapabilities"] ?? {}

// An Mcp-Session-Id from an older client is simply not read.
// Don't echo it, don't 400 on it.

The subtle one: state inferred from the connection

Deleting the session store is the obvious half. The half that survives a careless migration is any state a server still infers from the socket — a cached “this connection is authenticated” flag, a negotiated version held in a connection-scoped variable, a per-connection tool filter.

MCP-STL-008 is the one that catches this in practice, because a server filtering tools/list by something it learned earlier on the connection will return different lists to identical requests. That breaks client-side caching, and it is precisely what the caching metadata added in the same revision assumes cannot happen.

GET, DELETE and Last-Event-ID

Three smaller consequences, all SHOULD-level. They exist because the legacy transport used a standalone GET stream and a DELETE to tear a session down — with no sessions, neither has anything to act on.

Stream resumption goes with them. Last-Event-ID resumed a stream that outlived a request; modern streams do not, so the header is ignored rather than honoured.

If your server genuinely needs state

Plenty of servers legitimately need continuity — a long-running job, a paginated cursor, a multi-step workflow. Statelessness does not forbid that. It forbids the transport from carrying it implicitly.

// Server returns a handle as ordinary result data
{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "resultType": "complete",
    "content": [{ "type": "text", "text": "Export started." }],
    "structuredContent": { "jobId": "job_01HZY…" }
  }
}

// Client passes it back as a normal tool argument
{
  "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": {
    "name": "check_export",
    "arguments": { "jobId": "job_01HZY…" },
    "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" }
  }
}

The difference is that the handle is visible, explicit, and scoped by your own authorization checks — instead of being an ambient property of a TCP connection that a proxy might reuse or a serverless platform might drop.

The 8 statelessness rules we check

These are live from our rule catalogue, each traced to the spec sentence it comes from. fail means a MUST was violated; warn means a SHOULD was.

Frequently asked

Related