取消

Model Context Protocol（MCP）透過 notification message 支援對進行中請求的選用取消機制。當用戶端希望終止自己先前送出的請求時，SHOULD（應該）送出取消通知。

當伺服器終止一個訂閱串流時，伺服器 MUST（必須）送出 notifications/cancelled，並指向該 subscriptions/listen request ID；伺服器 MUST NOT（不得）基於其他目的送出這個取消通知。

取消流程

用戶端要取消進行中的請求時，會送出 notifications/cancelled，內容包括：

• 要取消的 request ID
• 選用的 reason 字串，可用於紀錄或顯示給使用者

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

依傳輸機制取消

用戶端如何表達取消，取決於使用中的 transport：

• Streamable HTTP：關閉 SSE response stream 就是取消訊號。伺服器 MUST（必須）把用戶端 disconnect 視為取消該請求；不需要、也不預期另外收到 notifications/cancelled。
• stdio：沒有可針對單一請求關閉的 stream，因此用戶端 MUST（必須）送出指向 request ID 的 notifications/cancelled。

逾時

實作 SHOULD（應該）為所有送出的請求設定 timeout，以避免連線永久懸置與資源耗盡。如果在期限內沒有收到成功或錯誤回應，發送方 SHOULD（應該）取消請求並停止等待：

• Streamable HTTP：關閉該請求的 response stream。
• stdio：送出指向該 request ID 的 notifications/cancelled。

SDK 與其他 middleware SHOULD（應該）允許以每個請求為單位設定 timeout。

實作在收到對應的 progress notification 時 MAY（可以）重設 timeout 計時，因為這表示工作仍在進行；但無論是否持續收到進度，實作 SHOULD（應該）始終保留最大 timeout 上限，以降低不正常用戶端或伺服器造成的影響。

行為要求

1. 取消通知 MUST（必須）只指向用戶端先前已送出，而且目前相信仍在處理中的請求。
2. 伺服器送出的取消通知 MUST（必須）只用於指向 subscriptions/listen，以結束該訂閱串流。
3. 伺服器收到取消通知後 SHOULD（應該）停止處理、釋放相關資源，並且不要再對被取消的請求送出 response。
4. 如果 request ID 不明、處理已完成，或操作本身無法取消，伺服器 MAY（可以）忽略取消通知。
5. 用戶端 SHOULD（應該）忽略取消後才抵達的任何 response。

時序考量

受網路延遲影響，取消通知可能在伺服器完成請求之後才抵達，甚至可能晚於 response。雙方 MUST（必須）能妥善處理這類 race condition：若工作尚未完成便停止處理；若工作已完成，則允許取消訊號失去作用，而用戶端忽略晚到的 response。

實作注意事項

• 雙方 SHOULD（應該）記錄 cancellation reason，以便除錯。
• 應用程式 UI SHOULD（應該）在取消已被要求時呈現適當狀態。

錯誤處理

無效的取消通知 SHOULD（應該）被忽略，包括未知 request ID、已完成的請求與格式錯誤的通知。這可保留 notification「fire and forget」的性質，同時容納非同步系統中的 race condition。