1.MCP 取消功能 #

协议修订: 2025-06-18

Model Context Protocol (MCP)支持通过通知消息可选地取消进行中的请求。任何一方均可发送取消通知，表明应终止先前发出的请求。

2.取消流程 #

当一方想要取消一个进行中的请求时，它会发送一个notifications/cancelled通知，包含以下信息：

• 要取消的请求ID - 指定需要取消的具体请求
• 可选的字符串原因 - 可用于记录或显示取消原因

2.1 取消通知示例 #

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

3. 行为要求 #

3.1 取消通知的有效性 #

取消通知必须仅引用满足以下条件的请求：

• 先前在同一方向上已发行过
• 被认为仍在进行中

3.2 初始化请求限制 #

initialize请求必须不被客户端取消。

3.3 接收方的处理要求 #

取消通知的接收方应该：

• 停止处理已取消的请求 - 立即终止相关操作
• 释放关联资源 - 清理已分配的内存、连接等资源
• 不发送对已取消请求的响应 - 避免发送无意义的响应

3.4 可忽略的情况 #

接收器可能在以下情况下忽略取消通知：

• 所引用的请求未知
• 处理已完成
• 该请求无法取消

3.5 发送方的后续处理 #

取消通知的发送方应该忽略之后对该请求的任何响应。

4. 时间考量 #

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

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

4.1 时序图示例 #

客户端                   服务器
  |                       |
  |-- 请求 -------------->|
  |                       |-- 处理开始
  |                       |
  |-- 通知/已取消 ------->|
  |                       |
  |                       |-- 处理可能已完成
  |                       |   取消到达
  |                       |
  |                       |-- 停止处理

5. 实现说明 #

5.1 调试和日志 #

• 双方应该记录取消原因用于调试
• 应用界面应该在取消请求时提供用户反馈

5.2 错误处理 #

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

• 未知请求ID - 无法找到对应的请求
• 已完成请求 - 请求已经处理完成
• 格式错误的通知 - 通知格式不符合规范

这保持了通知"发射后不管"的特性，同时允许异步通信中可能出现竞态条件。

6. 最佳实践 #

6.1 实现建议 #

• 及时响应 - 收到取消通知后立即停止处理
• 资源清理 - 确保所有相关资源得到正确释放
• 状态管理 - 维护准确的请求状态跟踪

6.2 用户体验 #

• 用户反馈 - 在UI中显示取消状态
• 进度指示 - 让用户了解取消操作的进度
• 错误处理 - 优雅处理取消失败的情况

6.3 调试支持 #

• 详细日志 - 记录取消的详细原因和时间
• 状态追踪 - 跟踪请求的完整生命周期
• 性能监控 - 监控取消操作的性能影响

7. 总结 #

MCP的取消功能为异步操作提供了重要的控制机制。通过正确实现取消流程，可以：

• 提高用户体验 - 允许用户控制长时间运行的操作
• 优化资源使用 - 避免不必要的计算和资源消耗
• 增强系统稳定性 - 防止资源泄漏和系统过载

关键要点：

• 取消通知必须引用有效的进行中请求
• 接收方应立即停止处理并释放资源
• 双方必须优雅处理网络延迟导致的竞态条件
• 提供适当的用户反馈和调试支持