跳到主要内容
协议修订: 2025-11-25
模型上下文协议 (MCP) 支持通过通知消息对正在进行的请求进行可选的取消。任何一方都可以发送取消通知，以表明之前发出的请求应被终止。

​
取消流程

当一方想要取消正在进行的请求时，它会发送一个 notifications/cancelled 通知，其中包含：
  • 要取消的请求 ID
  • 一个可选的、可用于日志记录或显示的理由字符串
{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "User requested cancellation"
  }
}

​
行为要求

  1. 取消通知必须 (MUST) 仅引用满足以下条件的请求：
    • 之前在相同方向发出的请求
    • 被认为仍在进行中的请求
  2. 客户端不得 (MUST NOT) 取消 initialize 请求
  3. 对于任务增强型请求，必须 (MUST) 使用 tasks/cancel 请求而非 notifications/cancelled 通知。任务拥有专门的取消机制，并会返回最终的任务状态。
  4. 取消通知的接收者应当 (SHOULD)：
    • 停止处理被取消的请求
    • 释放关联的资源
    • 不再为被取消的请求发送响应
  5. 在以下情况下，接收者可以 (MAY) 忽略取消通知：
    • 被引用的请求未知
    • 处理已经完成
    • 请求无法被取消
  6. 取消通知的发送者应当 (SHOULD) 忽略随后到达的对该请求的任何响应

​
时效性注意事项

由于网络延迟，取消通知可能会在请求处理完成后到达，甚至可能在响应已经发送之后。 双方必须 (MUST) 优雅地处理这些竞态条件：

​
实现笔记

  • 双方应当 (SHOULD) 记录取消理由以便调试
  • 应用程序 UI 应当 (SHOULD) 在请求取消时做出提示

​
错误处理

无效的取消通知应当 (SHOULD) 被忽略，例如：
  • 未知的请求 ID
  • 已经完成的请求
  • 格式错误的通知
这既保持了通知的“发后即忘”特性，又允许异步通信中存在竞态条件。