Mcp-Session-Id
Mcp-Session-Id is an HTTP header a Streamable HTTP server may return during initialize to identify a session. A client that receives one must echo it on every subsequent request. It lets a stateful server correlate calls across separate HTTP requests, and the 2026-07-28 revision, now current, removed it.
What is Mcp-Session-Id?
Mcp-Session-Id is an HTTP response header. A Streamable HTTP server that wants to keep state across requests issues one in its initialize response, and the client attaches it to every request that follows.
It belongs to revisions 2025-03-26 through 2025-11-25. The current revision, 2026-07-28, removed protocol-level sessions and tells a server to ignore the header and never issue one, so check which revision a server negotiated before debugging a missing session id.
Without it, each POST is an unrelated request, since HTTP is stateless and a single endpoint gives the server nothing else to correlate on.
How does a client get and send the session ID?
Read it once, then send it back every time. If the header is present in the initialize response, it becomes mandatory on subsequent requests; if it is absent, the server is stateless and the client sends nothing.
Our own handshake does exactly this: it reads mcp-session-id from the initialize response and, when the value is non-empty, adds it to the headers of every later request in that exchange. A client that drops the header mid-conversation can expect the server to reject the next call.
Do real servers use it?
We cannot say from our own data, and it is worth being precise about why. Our tester stores the JSON-RPC response bodies it received, not the response headers, so a session id is handled correctly at connection time and never recorded.
That means we have no measurement to publish here. Every other frequency in this glossary comes from stored payloads we can re-read; this one would be a guess, so there is no number attached to it.
Example
A stateful server answers initialize with Mcp-Session-Id: 1868a90c-4b3e-4f7a-a5e1-0f0a6e2b9c11. The client then sends that exact header on its tools/list call and on everything after it. Under the 2026-07-28 revision this disappears entirely, along with the initialize handshake that issues it, which is why an implementation should keep the whole exchange behind a version boundary rather than sprinkling header handling through its request code.