If an MCP response stream breaks mid-request, how does a 2026-07-28 client recover?

## What was removed Through revision 2025-11-25, MCP over HTTP could make a dropped stream survivable. The server attached ids to the events it emitted on a response stream, and a client that lost the connection could reconnect quoting `Last-Event-ID`; the server replayed from that point and the original request completed as though nothing had happened. Revision 2026-07-28 deleted that machinery — no SSE event ids, no `Last-Event-ID`, no replay — and put nothing in its place. ## The rule today A broken stream loses the in-flight request. The client's only recovery is to issue the call **again, as a new request, with a new JSON-RPC id**. Re-sending under the original id is wrong: the id is the correlation handle for one request/response pair, and a server that never finished the first one has no notion of resuming it. There is likewise nothing to ask for a partial result with — no `ping` (removed in the same revision), no per-request status probe in the core protocol. The same revision made stream closure meaningful in the other direction: on Streamable HTTP, closing the response stream **is** cancellation and the server MUST treat it as such. So a network drop and a deliberate client cancel look identical to the server. That is intentional and it is why the server side should be written to tolerate abandonment: the work may be halfway done, and the client may show up again with an identical call under a fresh id. ## Why this is acceptable Resumability was expensive for what it bought. To replay, a server has to buffer emitted events per request for some window, which is state — precisely the connection-scoped state the stateless redesign was trying to eliminate — and it forced load balancers into affinity so a reconnect reached the buffering node. Dropping it made an MCP endpoint an ordinary stateless POST endpoint, at the cost of pushing retry semantics up into the tool contract, where the tool author actually knows whether a repeat is safe. ## Making retries safe Since the client's only recovery is a repeat, retry safety has to be designed in: - **Prefer idempotent operations.** A read, a search, a query — repeating them costs latency and nothing else. - **Accept an idempotency key** for anything that mutates. Let the caller pass a stable key as an ordinary tool argument, deduplicate on it server-side, and return the original result for a repeat. This is the same technique any payments API uses, expressed as a tool parameter because MCP has no protocol-level slot for it. - **Do not lean on annotations.** `ToolAnnotations` offers `readOnlyHint` (default false), `destructiveHint` (default true), `idempotentHint` (default false) and `openWorldHint` (default true). They are hints for a client's UI and policy decisions, and clients MUST treat them as untrusted unless the server is trusted. They describe intent; they do not deduplicate anything. - **Bound the blast radius.** Cap how many times a client re-issues, and surface the failure to the user rather than silently hammering a tool whose stream keeps dying. ## The stdio companion rule Stdio has no per-request streams to break, but it has the same underlying principle: nothing survives a reconnect. If the subprocess connection is re-established, the client MUST re-send `subscriptions/listen` — the previous listen and its filter are gone. Notifications scoped to a specific request (`notifications/progress` and, when the caller asked for logs via `io.modelcontextprotocol/logLevel`, `notifications/message`) flow on the originating request's own response stream, so when that stream dies those notifications die with it and reappear only on the re-issued request. ## Answering well State the removal, state the exact replacement behaviour — new request, new id — and then move straight to the consequence the interviewer is actually probing: duplicate side effects, and where responsibility for them lives. Candidates who reach for `Last-Event-ID` are describing the 2025-11-25-and-earlier protocol.