取消

协议版本：2025-03-26

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

取消流程

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

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

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

行为要求

1. 取消通知必须仅引用：
   • 先前在同一方向发出的请求
   • believed 仍在进行中的请求
2. 客户端绝不能取消 initialize 请求
3. 取消通知的接收者应该：
   • 停止处理已取消的请求
   • 释放相关资源
   • 不为已取消的请求发送响应
4. 如果满足以下条件，接收者可以忽略取消通知：
   • 引用的请求未知
   • 处理已经完成
   • 请求无法取消
5. 取消通知的发送者应该忽略随后到达的请求的任何响应

时间考虑

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

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

  sequenceDiagram
   participant Client
   participant Server

   Client->>Server: 请求 (ID: 123)
   Note over Server: 处理开始
   Client--)Server: notifications/cancelled (ID: 123)
   alt
      Note over Server: 处理可能在<br/>取消到达之前<br/>已完成
   else 如果未完成
      Note over Server: 停止处理
   end

实现注意事项

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

错误处理

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

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

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