取消

模型上下文協議（MCP）通過通知消息支持可選的進行中請求取消。任何一方都可以發送取消通知，表明先前發出的請求應該終止。

取消流程

當一方想要取消進行中的請求時，它發送一個包含以下內容的 notifications/cancelled 通知：

• 要取消的請求的 ID
• 可以記錄或顯示的可選原因字符串

{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "用戶請求取消"
  }
}

行為要求

1. 取消通知必須只引用以下請求：
   • 先前在同一方向上發出的
   • 被認為仍在進行中的
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
• 已完成的請求
• 格式錯誤的通知

這保持了通知的"發送後忘記"性質，同時允許異步通信中的競爭條件。