Why architecture matters here
Agent workloads make cancellation load-bearing rather than optional. A single conversational turn can fan a plan into a dozen tool calls, several of which are slow (search, code execution, model-backed sub-agents) and expensive (metered APIs, GPU inference, paid data providers). Users interrupt constantly — they rephrase, they change their mind, they hit stop the instant they see the answer forming. Orchestrators cancel even more aggressively: a race between two retrieval strategies keeps the winner and abandons the loser; a speculative branch is dropped when a cheaper one suffices. Without real cancellation, every one of those abandonments leaves work running to completion — you pay for the loser of every race and the tail of every interrupted request.
The architecture matters because the naive mental model — 'closing the connection kills the work' — is false in MCP. Over a persistent stdio pipe or a streamable HTTP session, one transport multiplexes many concurrent requests; you cannot drop the socket to cancel one call without killing the others. Cancellation therefore has to be in-band and per-request, keyed on the request id, and the server has to be built to receive a message about a request it is currently in the middle of handling and act on it. That is a concurrency design decision, not a line of glue code: the handler must yield control at await points, a token must be visible to the code doing the slow work, and cleanup must run deterministically on the abandonment path.
Getting it right buys three things. Cost control: abandoned metered calls actually stop, so a user who cancels stops the meter. Resource hygiene: transactions roll back, file handles close, and connection pools do not bleed. Responsiveness: a server that promptly frees a slot when work is abandoned keeps its concurrency budget for live requests instead of clogging it with zombies. The teams that skip this ship demos that feel fast and production systems that fall over the first time a hundred users all hit stop at once.
The architecture: every piece explained
Top row: the requester side. When a client issues a request it records the requestId in a tracker alongside a cancellation primitive — in JavaScript an AbortController, in Python an asyncio.CancelledError-bearing task, in Go a context.Context. User action, timeout, or orchestrator decision aborts that primitive, and the client's job is twofold: send the notifications/cancelled message over the transport and locally resolve the pending call so the caller stops waiting. The transport carries the notification as an ordinary JSON-RPC message multiplexed with everything else; the server dispatcher that originally created a per-request context for the call now looks that context up by id.
Middle row: the server side, where the real engineering lives. The cancelled notification arrives with a requestId and optional reason. The dispatcher resolves it to the in-flight handler's context and trips a cancellation token — the server-side mirror of the client's abort primitive. That token is only useful if the handler checks it: at every await boundary, before each expensive step, and inside loops over large inputs. A tool that calls an HTTP client passes the token down so the socket read is itself abortable; a tool that runs a model streams tokens in a loop that breaks when the token trips. When the token fires, structured unwinding runs resource cleanup — rolling back the transaction, deleting the temp file, canceling the downstream metered call so spend stops — via try/finally or context managers, not scattered ad-hoc code.
Bottom rows: the race handling that makes it correct. Because a response and a cancellation can cross, the server must suppress any result produced after cancellation: it simply does not send a response for a cancelled id, and it does not send an error either — the request is abandoned, not failed. Symmetrically, the requester must tolerate a full response arriving after it sent the cancel (the race window): it ignores that late result. The protocol also forbids cancelling the special initialize request, which has no meaningful mid-flight state. The ops strip lists what keeps this honest in production: detecting orphaned work that ignored its token, measuring the latency from cancel-received to work-actually-stopped, counting leaked-work events, and carrying idempotency keys so a retried-then-cancelled operation cannot double-apply.
End-to-end flow
Trace a realistic cancellation. A coding agent asks an MCP server's run_tests tool to execute a project's suite — a 40-second operation that spawns a sandbox, installs dependencies, and streams output. The client records request id c-812 with an AbortController and awaits the result. Fifteen seconds in, the user edits a file and the IDE decides the stale run is worthless, so it aborts the controller.
The client does two things at once. It resolves the pending c-812 promise locally (rejecting it with an abort so the agent loop moves on) and it writes a notifications/cancelled message — {requestId: 'c-812', reason: 'superseded by edit'} — onto the transport. On the server, the dispatcher is mid-handler: the sandbox is running pytest and the handler is awaiting the process's output stream. The dispatcher looks up c-812's context and trips its cancellation token. At the next await boundary the handler observes the trip, breaks out of the output loop, and enters its finally block: it sends SIGTERM to the sandbox process group, waits briefly, SIGKILLs stragglers, unmounts the temp workspace, and returns the sandbox slot to the pool. No response is sent for c-812. Total time from cancel received to sandbox torn down: ~180ms, recorded as the cancel latency for this tool.
Now the race case. Imagine the suite had finished at second 15.0 and the handler had just serialized a passing result when the cancel arrived at 15.02. Two orderings are possible. If the response was already written to the transport, the client receives it after having sent the cancel; the client checks its tracker, sees c-812 already resolved/aborted, and drops the result on the floor — no error surfaced to the user. If the response had not yet been written, the server's suppression logic sees the id is cancelled and declines to send it. Either way the protocol stays consistent: exactly zero or one response, never a cancel-plus-error confusion.
Finally the point-of-no-return case. Suppose the tool had already POSTed a deployment to a metered external API before the cancel arrived. The handler cannot un-send that call, so cancellation here is genuinely best-effort: it stops polling for the deploy result and releases local resources, but the external side effect stands. This is why idempotency keys and compensating actions matter — the server records that c-812 committed an external effect, so a subsequent retry reuses the key rather than deploying twice, and an operator dashboard flags the abandoned-but-committed operation for reconciliation. The honest framing throughout: cancellation stops future work reliably and in-progress external effects only sometimes.