In MCP Streamable HTTP, what does closing the response stream mean to the server?

## The rule In MCP revision 2026-07-28, when a server has upgraded a response to a stream, that stream carries the notifications and the final response for **one** request. Because the mapping is one to one, the transport can express cancellation with nothing more than a socket close: the specification says a server MUST treat the client closing the response stream as cancellation of that request. There is no acknowledgement to send and nothing to reply to — the channel that a reply would travel on is the one that just closed. The server's obligation is to stop working. ## Why the design is like this A stateless, one-endpoint transport has no session to hang a lifecycle on. What it does have is a TCP connection per in-flight request, and the semantics of that connection are already precise: while it is open the client is waiting for this answer, and when it closes the client is not. Rather than invent a second mechanism, the spec adopts the one the transport already gives you. The explicit `notifications/cancelled` message still exists and is the polite form — it lets a client cancel while keeping the connection, and it is the only mechanism available on transports without per-request streams. But an implementation that only listens for that notification and ignores a dropped stream will keep burning CPU, holding database connections and calling paid downstream APIs for requests nobody is waiting for. ## The failure mode this creates The hazard is that *nothing about a dropped connection distinguishes intent*. Consider a tool call that takes 90 seconds and emits nothing while it works: - A reverse proxy with a 60-second idle read timeout closes the stream. The server sees a close, cancels, and the client sees a truncated request. Nobody chose this. - A load balancer enforces a maximum request duration and does the same at a fixed wall-clock point. - The user closes the tab; the browser tears down the connection mid-call. - An HTTP client library applies a total-request timeout and aborts. Each of these is indistinguishable at the server from a deliberate cancel. So the reliability of long MCP calls is bounded by the *most impatient hop in the path*. ## Hardening a long-running call **Keep the stream non-idle.** Idle timeouts measure time since the last byte. A server that emits `notifications/progress` on the request's own stream every few seconds resets that clock everywhere along the path, and gives the user something to look at. This is the single highest-value mitigation. **Raise idle timeouts deliberately, at every hop.** The application server, the reverse proxy, the load balancer, any service mesh sidecar, and the client library all have their own. The effective timeout is the minimum, and it is usually not the one you configured. **Disable response buffering for the endpoint.** A proxy that buffers the response body defeats the previous two points completely: your progress events are held in the proxy's buffer, the downstream connection stays idle, and it times out anyway — while your server logs show it dutifully streaming. **Make cancellation real.** Plumb the closed-stream signal into the work: cancel the context or token, interrupt the downstream HTTP call, roll back or compensate. A server that merely stops writing to a dead socket while its worker runs to completion has implemented the letter of the rule and none of its value — and under retry pressure that is how you get an overload spiral, every cancelled call still consuming resources while its replacement starts. **Consider not holding the connection at all.** If work genuinely takes minutes, keeping an HTTP response open for it is fragile by construction. The `io.modelcontextprotocol/tasks` extension exists for exactly this shape of workload: the call returns promptly with a handle, and the client polls or subscribes for the outcome, so no infrastructure timeout can destroy the work. ## Idempotency and retries Cancellation says nothing about whether the side effect happened. A tool that charged a card and then had its stream closed has still charged the card. Because a client that loses a stream will typically re-issue the request as a brand-new call with a new id, tools with side effects need an idempotency story of their own — a caller-supplied key, or a design where re-execution is harmless. Advertising `idempotentHint` on a tool is a hint to the client, not a guarantee, and it does not make an operation safe by itself. ## What an interviewer is probing The fact — "closing the stream is cancellation" — is one sentence. The senior signal is everything after it: that the rule turns every timeout in your infrastructure into a cancellation source, that progress notifications are a keepalive as much as a UX feature, that buffering proxies silently break the whole scheme, and that cancellation must reach the work rather than just the socket.