Skip to content

Cancellation

Documentation Index

完全なドキュメント索引は modelcontextprotocol.io/llms.txt で取得してください。 さらに調べる前に、このファイルを使って利用可能なすべてのページを見つけてください。

MCP は、notification メッセージを通じて、進行中の request を任意でキャンセルする仕組みをサポートしています。どちらの側も cancellation notification を送信して、以前に発行された request を終了させるべきことを示せます。

Cancellation Flow

進行中の request をキャンセルしたい場合、その当事者は notifications/cancelled notification を送信します。この notification には、次の内容を含めます。

  • キャンセル対象の request の ID
  • ログ出力や表示に使える、省略可能な reason 文字列
{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "User requested cancellation"
  }
}

Behavior Requirements

  1. cancellation notification は、次の条件を満たす request だけを参照しなければなりません (MUST)。
    • 以前に同じ方向で発行されたものである
    • なお進行中であると考えられている
  2. クライアントは initialize request をキャンセルしてはなりません (MUST NOT)。
  3. task-augmented requests では、notifications/cancelled notification の代わりに tasks/cancel request を使わなければなりません (MUST)。Task には専用のキャンセル機構があり、最終的な task state を返します。
  4. cancellation notification を受け取った側は、次のようにするべきです (SHOULD)。
    • キャンセルされた request の処理を停止する
    • 関連するリソースを解放する
    • キャンセルされた request に対する response を送信しない
  5. 受信側は、次の場合には cancellation notification を無視してもかまいません (MAY)。
    • 参照された request が不明である
    • 処理がすでに完了している
    • その request をキャンセルできない
  6. cancellation notification の送信側は、その後に到着した当該 request への response を無視するべきです (SHOULD)。

Timing Considerations

ネットワーク遅延のため、cancellation notification は request の処理完了後に到着する場合があり、場合によっては response がすでに送信された後である可能性もあります。

両当事者は、これらの race condition を適切に扱わなければなりません (MUST)。

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

Implementation Notes

  • 両当事者は、デバッグのためにキャンセル理由をログに記録するべきです (SHOULD)。
  • アプリケーション UI は、キャンセルが要求されたことを示すべきです (SHOULD)。

Error Handling

無効な cancellation notification は無視するべきです (SHOULD)。

  • 不明な request ID
  • すでに完了した request
  • 不正な形式の notification

これにより、非同期通信における race condition を許容しつつ、notification の「fire and forget」という性質を保てます。