Sessions & Reconnection

A remote server may handle many clients at once. To keep each conversation straight, it needs a way to remember who is who: that is a session. 🧠

A session starts during the initialize handshake. The server greets the new client and sets up the state that will track this connection.

To label a session, the server returns a unique Mcp-Session-Id header in its initialize reply. Think of it as the client's claim ticket.

On every later request, the client includes that same id in its headers. The server reads it and knows exactly which session this call belongs to.

Anything the server should remember between calls, like a logged-in user or a cursor, hangs off the session. Different clients never see each other's data.

Not every server needs memory. A stateless server treats each request as standalone and issues no session id, which makes scaling much simpler.

Over the internet, links break: a stream can die mid-reply. A good transport must handle a dropped connection without losing the whole session. 📡

Remember SSE event ids? The client reconnects and sends the Last-Event-ID it saw, asking the server to replay only what came after.

Because each event was numbered, replay is precise. The client misses nothing and sees nothing twice, so a hiccup never corrupts the result.

When a client is done, it can send an HTTP DELETE to the endpoint with its session id. The server frees the state, keeping memory tidy.

Together, sessions and reconnection make a remote server feel reliable: it remembers your context and survives flaky networks gracefully. ✨

How does a client prove which session a request belongs to?

A session id, set at init and echoed back, ties each client to its state. Numbered SSE events let a dropped stream resume cleanly with no gaps. 🎉