Cancellation ↗

Documentation Index#

Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt Use this file to discover all available pages before exploring further.

Protocol Revision: 2025-11-25

The Model Context Protocol (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.

Cancellation Flow#

When a party wants to cancel an in-progress request, it sends a notifications/cancelled notification containing:

• The ID of the request to cancel
• An optional reason string that can be logged or displayed

{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "User requested cancellation"
  }
}

Behavior Requirements#

1. Cancellation notifications MUST only reference requests that:
   • Were previously issued in the same direction
   • Are believed to still be in-progress
2. The initialize request MUST NOT be cancelled by clients
3. For task-augmented requests, the tasks/cancel request MUST be used instead of the notifications/cancelled notification. Tasks have their own dedicated cancellation mechanism that returns the final task state.
4. Receivers of cancellation notifications SHOULD:
   • Stop processing the cancelled request
   • Free associated resources
   • Not send a response for the cancelled request
5. Receivers MAY ignore cancellation notifications if:
   • The referenced request is unknown
   • Processing has already completed
   • The request cannot be cancelled
6. The sender of the cancellation notification SHOULD ignore any response to the request that arrives afterward

Timing Considerations#

Due to network latency, cancellation notifications may arrive after request processing has completed, and potentially after a response has already been sent.

Both parties MUST handle these race conditions gracefully:

sequenceDiagram
   participant Client
   participant Server

   Client->>Server: Request (ID: 123)
   Note over Server: Processing starts
   Client--)Server: notifications/cancelled (ID: 123)
   alt
      Note over Server: Processing may have<br/>completed before<br/>cancellation arrives
   else If not completed
      Note over Server: Stop processing
   end

Implementation Notes#

• Both parties SHOULD log cancellation reasons for debugging
• Application UIs SHOULD indicate when cancellation is requested

Error Handling#

Invalid cancellation notifications SHOULD be ignored:

• Unknown request IDs
• Already completed requests
• Malformed notifications

This maintains the “fire and forget” nature of notifications while allowing for race conditions in asynchronous communication.