> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.gjxx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 取消

<div id="enable-section-numbers" />

<Info>**协议修订版**：draft</Info>

Model Context Protocol (MCP)通过通知消息支持对进行中请求的可选取消。任何一方都可以发送取消通知来指示应终止之前发出的请求。

## 取消流程

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

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

```json theme={null}
{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "User requested cancellation"
  }
}
```

## 行为要求

1. 取消通知**必须**仅引用：
   * 在同一方向上之前发出的请求
   * 被认为仍在进行中的请求
2. 客户端**不得**取消`initialize`请求
3. 取消通知的接收者**应该**：
   * 停止处理已取消的请求
   * 释放关联的资源
   * 不为已取消的请求发送响应
4. 接收者**可以**忽略取消通知，如果：
   * 引用的请求未知
   * 处理已完成
   * 请求无法取消
5. 取消通知的发送者**应该**忽略随后到达的对请求的任何响应

## 时间考虑

Due to network latency, cancellation notifications may arrive after request processing
has completed, and potentially after a response has already been sent.

Both parties **MUST** handle these race conditions gracefully:

```mermaid theme={null}
sequenceDiagram
   participant Client
   participant Server

   Client->>Server: Request (ID: 123)
   Note over Server: Processing starts
   Client--)Server: notifications/cancelled (ID: 123)
   alt
      Note over Server: Processing may have<br/>completed before<br/>cancellation arrives
   else If not completed
      Note over Server: Stop processing
   end
```

## 实施说明

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

## 错误处理

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

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

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