67 lines
No EOL
1.9 KiB
Text
67 lines
No EOL
1.9 KiB
Text
---
|
|
title: Cancellation
|
|
---
|
|
|
|
MCP supports request cancellation through a dedicated notification message. This allows either party to signal that they are no longer interested in the result of an in-flight request.
|
|
|
|
## Cancellation Protocol
|
|
|
|
When a party wants to cancel a request, they send a "cancelled" notification containing the ID of the request they wish to cancel:
|
|
|
|
For example, initiating a request:
|
|
|
|
```json
|
|
{
|
|
"jsonrpc": "2.0",
|
|
"id": "abc123",
|
|
"method": "resources/read",
|
|
"params": {
|
|
"uri": "example://large-file"
|
|
}
|
|
}
|
|
```
|
|
|
|
… then some time later, cancelling that request:
|
|
|
|
```json
|
|
{
|
|
"jsonrpc": "2.0",
|
|
"method": "notifications/cancelled",
|
|
"params": {
|
|
"requestId": "abc123",
|
|
"reason": "User interrupted operation"
|
|
}
|
|
}
|
|
```
|
|
|
|
## Handling Cancellation
|
|
|
|
Upon receiving a cancellation notification, the receiver SHOULD:
|
|
|
|
1. Stop any processing related to the cancelled request
|
|
2. Free any resources associated with that request
|
|
3. Not send a response for the cancelled request (even if already computed)
|
|
|
|
However, due to race conditions and message latency:
|
|
|
|
- The notification may arrive after processing is complete
|
|
- A response may already be in transit when cancellation is received
|
|
- Multiple cancellation notifications for the same request ID may be received
|
|
|
|
## Special Cases
|
|
|
|
### Initialize Request
|
|
|
|
The client MUST NOT attempt to cancel its `initialize` request. Cancelling initialization leaves the protocol in an undefined state.
|
|
|
|
### Long-Running Operations
|
|
|
|
For long-running operations that support progress notifications, progress notifications SHOULD stop being sent after receiving cancellation.
|
|
|
|
## Best Practices
|
|
|
|
1. Implement cancellation handlers for all long-running operations
|
|
2. Free resources promptly when receiving cancellation
|
|
3. Make cancellation handling idempotent
|
|
4. Include meaningful reason strings to aid debugging
|
|
5. Log cancellations appropriately for troubleshooting |