On MCP's stdio transport, how does a client cancel an in-flight request?

## Why stdio needs an explicit message On the stdio binding both peers share exactly one channel in each direction. Every request, response and notification is interleaved on the same stdin and stdout pipes and correlated only by the JSON-RPC `id`. There is no per-request stream, so there is no per-request thing to close — closing stdin would stop the entire server, not one call. Cancellation therefore has to travel in-band as a message like anything else. That is a genuine difference from the HTTP binding, where each request has its own response stream and closing that stream **is** the cancellation signal, which the server must honour. ## The mechanism The client writes `notifications/cancelled` to the server's stdin, naming the `requestId` of the request it wants abandoned; an optional human-readable reason may accompany it. Because it is a JSON-RPC *notification* it carries no `id` of its own and receives no response — you never get an acknowledgement that the cancellation was honoured. The same notification also serves in the other direction as the way either side steps away from long-lived work, including tearing down a `subscriptions/listen` stream. ## Best-effort semantics Cancellation is advisory, and every serious answer says so: - **The race is unavoidable.** By the time the notification is parsed, the server may already have written the response. Messages cross on the wire, so the client must tolerate a result arriving for a request it cancelled and discard it. - **Side effects are not undone.** A tool that has already sent the email, charged the card or deleted the file cannot un-do it on cancellation. Cancellation stops *further* work; it is not a rollback. - **Cooperation is required.** A server stuck in a blocking syscall may not notice the notification at all. Nothing in the protocol can force it. So the client's own state machine is what actually implements the cancellation: it settles the pending call locally (typically as cancelled), stops charging the user for it, and ignores anything that later arrives bearing that id. ## Hygiene rules **Do not reuse the id.** JSON-RPC ids must stay unique for the connection's lifetime; a cancelled id is spent. If the client wants the work retried it sends a new request with a new id — which is also exactly how 2026-07-28 handles a stream that breaks, since every request is self-contained and nothing is resumable. **Do not cancel what was never sent.** A cancellation for an unknown or already-completed id should be ignored by the receiver rather than turned into an error; it is a normal consequence of the race. **Do not kill the process.** Terminating the subprocess is a shutdown, not a cancellation: it destroys every other concurrent request and forces a relaunch. Reach for it only when the server is genuinely wedged. **Timeouts are the other half.** Because a cancellation may be ignored, a client should also enforce its own per-request timeout, and cancelling on timeout is the normal pairing: give up locally, tell the server so it can stop burning CPU. ## Progress and long calls Long-running work is usually the reason to cancel, and the pieces fit together: a client that supplies a `progressToken` in a request's `_meta` receives `notifications/progress` for that request, giving the user something to watch and a sensible moment to press cancel. Under 2026-07-28 those request-scoped notifications flow on the originating request's own response path — on stdio, that is simply the shared stdout stream, tagged by the token. For genuinely long jobs the better structure is often the `io.modelcontextprotocol/tasks` extension, whose cooperative cancellation is a separate mechanism, but for an ordinary in-flight call on stdio, `notifications/cancelled` is the tool.