Wiki · Concept · Last reviewed June 25, 2026

MCP Cancellation

MCP cancellation is the Model Context Protocol utility for requesting that a previously issued, still in-progress request stop through a cancellation notification.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Cancellation, AI Agents, Long-Running Operations, Governance

Definition

MCP cancellation is a base utility in the Model Context Protocol. The 2025-11-25 specification says MCP supports optional cancellation of in-progress requests through notification messages. Either side can send a cancellation notification to indicate that a previously issued request should be terminated.

The important word is "request." Cancellation does not delete a resource, undo an external side effect, or prove that execution stopped at the exact moment the user clicked a button. It is a protocol signal: the result will not be used, and the receiver should stop associated work where it can.

How It Works

When a party wants to cancel an in-progress request, it sends a notifications/cancelled notification. The notification contains the requestId of the request to cancel and may contain a human-readable reason string that can be logged or displayed. The cancellation page requires cancellation notifications to reference requests that were previously issued in the same direction and are believed to still be in progress.

Receivers should stop processing the cancelled request, free associated resources, and not send a response for that cancelled request. Receivers may ignore a cancellation notification if the referenced request is unknown, processing has already completed, or the request cannot be cancelled. The sender should ignore any response that arrives afterward.

The specification also calls out race conditions. Because of network latency, a cancellation notification may arrive after the request has already completed, potentially even after a response was sent. Both sides must handle those timing cases gracefully.

Tasks and Timeouts

Cancellation has a separate boundary for MCP Tasks. For task-augmented requests, the cancellation page says tasks/cancel must be used instead of notifications/cancelled. Tasks have their own cancellation mechanism because they are durable state machines that return a final task state.

The lifecycle specification connects cancellation to timeouts. Implementations should establish timeouts for all sent requests to prevent hung connections and resource exhaustion. If a request has not received a success or error response within the timeout period, the sender should issue a cancellation notification for that request and stop waiting. The lifecycle page also says implementations may reset timeout clocks when corresponding progress notifications arrive, while still enforcing a maximum timeout.

Governance Requirements

A governed deployment should log the original request ID, method, sender, receiver, start time, cancellation time, cancellation reason, whether a response later arrived, whether associated compute or tool execution actually stopped, and whether external side effects may already have occurred. For task cancellation, the record should include the task ID, prior task status, final task status, and result-retention rule.

User interfaces should distinguish "cancellation requested" from "work stopped." The former is a protocol event; the latter is an operational fact that may require confirmation from the receiver, task state, logs, or external system records.

Failure Modes

Cancellation theater. The interface says a request was cancelled, but execution continues in a tool, queue, browser, shell, or external API.

Late response confusion. A receiver sends a response after cancellation and the sender accidentally treats it as usable output.

Wrong boundary. A client uses notifications/cancelled for a task-augmented request instead of tasks/cancel.

Reason leakage. The reason string includes sensitive user intent, file names, secrets, or internal incident details that later appear in logs or UI.

Source Discipline

Claims about MCP cancellation should cite the versioned cancellation specification. Claims about task-specific cancellation should cite both the cancellation and tasks pages. Claims about request timeouts should cite the lifecycle page. Security and logging recommendations should be identified as governance guidance unless directly grounded in the MCP security documentation.

Spiralist Reading

Cancellation is the user's claim that agency remains available after delegation. It says the machine was not merely started; it can still be interrupted.

The Spiralist caution is that interruption has to be real. A stop button that only changes the screen is comfort theater. A trustworthy system records the request to stop, shows what stopped, admits what may have escaped, and keeps enough evidence for review.

Open Questions

Sources

Return to Wiki