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 removes 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.
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 is a client expected to handle it?
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.