On stdio, what must an MCP client do about subscriptions/listen after a reconnect?

## The rule On the stdio transport, after a reconnect the client **MUST** re-send `subscriptions/listen`. This is stated as a client obligation in MCP revision **2026-07-28**, and it follows directly from the era's core framing: MCP is a stateless protocol, every request is self-contained, and "an open connection, such as a STDIO process, is not a conversation or session". ## Why stdio makes this vivid On stdio, an MCP server is a subprocess the client launched, communicating over newline-delimited JSON-RPC on stdin/stdout. "Reconnect" therefore usually means one of two things: - the server process crashed or exited and the client started a new one, or - the host restarted and relaunched its configured servers. Either way the new process has no memory of the previous one. Any in-flight requests died with it, including the long-outstanding `subscriptions/listen` request. There is no identifier the client could present to claim the old subscription — protocol-level sessions and the `Mcp-Session-Id` header were removed in 2026-07-28 precisely so that no such implicit continuity exists. The stdio channel also shapes how a subscription lives while it is running. There is one shared stdin/stdout pair, not a stream per request, so the listen "stream" is simply an outstanding request whose notifications interleave with everything else on the channel. That is also why cancelling it uses `notifications/cancelled` rather than closing a per-request stream. ## What is lost, and how to recover There is **no replay and no resumability** in 2026-07-28. `Last-Event-ID` and SSE event ids were removed, and nothing in the protocol lets a client say "catch me up from here". Everything that changed during the outage — a tool appearing, a watched file being edited — is invisible to the client afterwards, unless it goes and looks. So the recovery sequence is: 1. Relaunch or reattach to the server process. 2. Send `subscriptions/listen` again with the filter you want. Remember that on stdio, version and capabilities travel in `_meta` on this request as on every other one — there is no header layer and no handshake to establish them. 3. Wait for `notifications/subscriptions/acknowledged`, the mandatory first message, before treating push as live. 4. Re-fetch whatever the subscription was protecting: `tools/list`, `prompts/list`, `resources/list`, or the specific resources you were watching. This closes the gap the outage opened. 5. Discard any late messages carrying the old `io.modelcontextprotocol/subscriptionId`, if your client can still receive them. Step 4 is the one implementers skip and then debug for a day: the subscription is technically re-established, the acknowledgement arrived, and yet the palette shows tools that no longer exist because the `list_changed` notification fired while the process was down. ## The same rule in different clothes on HTTP The stdio rule is spelled out explicitly because a subprocess restart is the common case there, but the underlying principle is transport-independent. On Streamable HTTP a broken response stream also loses the in-flight request, and the client must issue a **new** request with a **new** JSON-RPC id rather than resuming — again because resumability was removed. A listen stream is just the longest-lived instance of that rule. ## Design consequences for clients A client library should own subscription re-establishment rather than leaving it to feature code. In practice that means keeping the desired filter as declarative state ("I want tool-list changes from server X and updates to these three files"), and having a supervisor that, whenever a connection is established, drives the sequence: listen, await acknowledgement, resynchronise caches. Feature code should never have to remember to re-subscribe. Backoff matters too. A server that crashes on startup will be relaunched, subscribed to, and crashed again in a tight loop unless the client backs off, and on stdio that loop is process spawning, not just socket dialling. ## Interview framing Say the MUST plainly, then justify it from statelessness: a stdio connection is not a session, so nothing carries over, and there is no resumability to lean on. Then add the part that separates an implementer from a reader — re-listing after re-subscribing, because the gap is not replayed. That sequencing answer is what a senior interviewer is listening for.