Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt

Use this file to discover all available pages before exploring further.

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

​
取消流程

当一方想要取消进行中的请求时，它会发送一个 notifications/cancelled 通知，包含：
  • 要取消的请求 ID
  • 一个可选的原因字符串，可用于记录或显示
{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "用户请求取消"
  }
}

​
特定于传输的取消

客户端如何发出取消信号取决于传输方式：
  • Streamable HTTP：关闭 SSE 响应流即表示取消信号。
    服务器必须将客户端断开连接视为该请求的取消。不需要也不应期望 notifications/cancelled 消息。
  • stdio：没有可关闭的按请求流。客户端必须发送一个引用该请求 ID 的 notifications/cancelled 通知。

​
行为要求

  1. 取消通知必须只引用以下请求：
    • 之前在同一方向上发出的请求
    • 被认为仍处于进行中状态的请求
  2. 取消通知的接收方应该：
    • 停止处理已取消的请求
    • 释放相关资源
    • 不要为已取消的请求发送响应
  3. 接收方可以忽略取消通知，如果：
    • 所引用的请求未知
    • 处理已经完成
    • 该请求无法取消
  4. 取消通知的发送方应该忽略之后到达的任何该请求响应

​
时序考虑

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

​
实现说明

  • 双方应该记录取消原因以便调试
  • 应用程序 UI 应该在请求取消时予以指示

​
错误处理

无效的取消通知应该被忽略：
  • 未知的请求 ID
  • 已完成的请求
  • 格式错误的通知
这保持了通知的“即发即弃”特性，同时允许异步通信中存在竞态条件。