取消

• 1 取消流程
• 2 行为要求
• 3 时序考虑
• 4 实现注意事项
• 5 错误处理

协议版本: 2025-11-25

模型上下文协议（MCP）通过通知消息支持可选的取消正在进行的请求。任何一方都可以发送取消通知，以指示应终止先前发出的请求。

1 取消流程

当一方想要取消正在进行的请求时，它发送一个 notifications/cancelled 通知，包含：

• 要取消的请求的 ID
• 可以记录或显示的可选原因字符串

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

2 行为要求

1. 取消通知必须仅引用以下请求：
   • 之前在同一方向发出的
   • 被认为仍在进行中的
2. 客户端禁止取消 initialize 请求
3. 对于任务增强的请求，必须使用 tasks/cancel 请求而不是 notifications/cancelled 通知。任务有自己专用的取消机制，可返回最终任务状态。
4. 取消通知的接收者应该：
   • 停止处理被取消的请求
   • 释放关联的资源
   • 不为被取消的请求发送响应
5. 接收者可以在以下情况下忽略取消通知：
   • 引用的请求未知
   • 处理已完成
   • 请求无法取消
6. 取消通知的发送者应该忽略之后到达的对请求的任何响应

3 时序考虑

由于网络延迟，取消通知可能在请求处理完成后到达，并且可能在响应已经发送之后到达。

双方必须优雅地处理这些竞态条件：

4 实现注意事项

• 双方应该记录取消原因以供调试
• 应用程序 UI 应该指示何时请求了取消

5 错误处理

无效的取消通知应该被忽略：

• 未知的请求 ID
• 已完成的请求
• 格式错误的通知

这维持了通知的"发送即忘"性质，同时允许异步通信中的竞态条件。