Tasks

Documentation Index

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

Tasks は MCP 仕様のバージョン 2025-11-25 で導入され、現在は experimental と見なされています。 Tasks の設計と挙動は、将来のプロトコルバージョンで変更される可能性があります。

Model Context Protocol (MCP) では、requestor が request を tasks で拡張できます。requestor は通信方向に応じて client にも server にもなりえます。Tasks は、ラップしている request の基底となる実行状態に関する情報を保持する、永続的な状態機械です。これは requestor によるポーリングと、後からの結果取得を意図したものです。各 task は、receiver が生成する一意な task ID によって識別されます。

Tasks は、高コストな計算やバッチ処理 request を表現するのに有用であり、外部のジョブ API とも自然に統合できます。

Definitions

Tasks では、当事者を "requestor" または "receiver" として表現します。定義は次のとおりです。

Requestor: task-augmented request の送信者です。これは client の場合も server の場合もあり、どちらも task を作成できます。
Receiver: task-augmented request の受信者であり、その task を実行する主体です。これは client の場合も server の場合もあり、どちらも task を受信して実行できます。

User Interaction Model

Tasks は requestor-driven として設計されています。つまり、requestor が request を tasks で拡張し、その結果をポーリングして取得する責任を持ちます。一方で、receiver はどの request が task ベースの実行をサポートするかを厳密に制御し、それらの task のライフサイクルを管理します。

この requestor-driven なアプローチにより、deterministic な response 処理が保証され、同時実行 request の振り分けのような高度なパターンも実現できます。これを適切にオーケストレーションできるだけの十分な文脈を持っているのは requestor だけだからです。

実装は、Tasks を任意のインターフェイスパターンで公開してかまいません。プロトコル自体は特定のユーザー操作モデルを義務付けません。

Capabilities

task-augmented requests をサポートする server と client は、初期化時に tasks capability を宣言しなければなりません (MUST)。tasks capability は request category ごとに構造化されており、どの特定の request type が task augmentation をサポートするかを示す boolean プロパティを持ちます。

Server Capabilities

Server は、tasks をサポートしているかどうか、またサポートする場合はどの server-side request が tasks で拡張可能かを宣言します。

Capability	Description
`tasks.list`	Server が `tasks/list` operation をサポートする
`tasks.cancel`	Server が `tasks/cancel` operation をサポートする
`tasks.requests.tools.call`	Server が task-augmented `tools/call` request をサポートする

{
  "capabilities": {
    "tasks": {
      "list": {},
      "cancel": {},
      "requests": {
        "tools": {
          "call": {}
        }
      }
    }
  }
}

Client Capabilities

Client は、tasks をサポートしているかどうか、またサポートする場合はどの client-side request が tasks で拡張可能かを宣言します。

Capability	Description
`tasks.list`	Client が `tasks/list` operation をサポートする
`tasks.cancel`	Client が `tasks/cancel` operation をサポートする
`tasks.requests.sampling.createMessage`	Client が task-augmented `sampling/createMessage` request をサポートする
`tasks.requests.elicitation.create`	Client が task-augmented `elicitation/create` request をサポートする

{
  "capabilities": {
    "tasks": {
      "list": {},
      "cancel": {},
      "requests": {
        "sampling": {
          "createMessage": {}
        },
        "elicitation": {
          "create": {}
        }
      }
    }
  }
}

Capability Negotiation

初期化フェーズの間に、両当事者は tasks capability を交換して、どの operation が task-based execution をサポートするかを確立します。requestor は、対応する capability が receiver によって宣言されている場合にのみ、request を task で拡張するべきです (SHOULD)。

たとえば、ある server の capability に tasks.requests.tools.call: {} が含まれていれば、client は tools/call request を task で拡張できます。ある client の capability に tasks.requests.sampling.createMessage: {} が含まれていれば、server は sampling/createMessage request を task で拡張できます。

capabilities.tasks が定義されていない場合、peer は request 時に task を作成しようとするべきではありません (SHOULD NOT)。

capabilities.tasks.requests にある capability の集合は exhaustive です。ある request type が存在しない場合、その request type は task-augmentation をサポートしません。

capabilities.tasks.list は、tasks/list operation がその当事者によってサポートされるかどうかを制御します。

capabilities.tasks.cancel は、tasks/cancel operation がその当事者によってサポートされるかどうかを制御します。

Tool-Level Negotiation

Tool call は、task augmentation の目的において特別に扱われます。tools/list の結果の中で、tool は execution.taskSupport によって tasks サポートを宣言します。これが存在する場合、その値は "required"、"optional"、または "forbidden" のいずれかになります。

これは capability に加わる、より細かい粒度のレイヤーとして解釈され、次のルールに従います。

server の capability に tasks.requests.tools.call が含まれていない場合、execution.taskSupport の値に関係なく、client はその server の tool で task augmentation を使おうとしてはなりません (MUST NOT)。
server の capability に tasks.requests.tools.call が含まれている場合、client は execution.taskSupport の値を考慮し、それに応じて処理します。
1. execution.taskSupport が存在しない、または "forbidden" の場合、client はその tool を task として呼び出そうとしてはなりません (MUST NOT)。client がそう試みた場合、server は -32601 (Method not found) エラーを返すべきです (SHOULD)。これがデフォルトの挙動です。
2. execution.taskSupport が "optional" の場合、client はその tool を task としても通常の request としても呼び出してかまいません。
3. execution.taskSupport が "required" の場合、client はその tool を task として呼び出さなければなりません (MUST)。client がそうしなかった場合、server は -32601 (Method not found) エラーを返さなければなりません (MUST)。

Protocol Messages

Creating Tasks

task-augmented request は、通常の request とは異なる 2 段階の response パターンに従います。

Normal requests: server が request を処理し、実際の operation result を直接返します。
Task-augmented requests: server が request を受理し、直ちに task data を含む CreateTaskResult を返します。実際の operation result は、その task が完了した後に tasks/result を通じて取得できるようになります。

task を作成するには、requestor は request params に task フィールドを含めた request を送信します。requestor は、作成時点からの希望する task lifetime（ミリ秒）を示す ttl 値を含めてもかまいません。

Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "New York"
    },
    "task": {
      "ttl": 60000
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
      "status": "working",
      "statusMessage": "The operation is now in progress.",
      "createdAt": "2025-11-25T10:30:00Z",
      "lastUpdatedAt": "2025-11-25T10:40:00Z",
      "ttl": 60000,
      "pollInterval": 5000
    }
  }
}

receiver が task-augmented request を受理した場合、task data を含む CreateTaskResult を返します。この response には実際の operation result は含まれません。実際の result（たとえば tools/call に対する tool result）は、その task が完了した後でのみ tasks/result を通じて取得できます。

tools/call request に対する response として task が作成された場合、host application は task の実行中に model に制御を返したいことがあります。これにより model は、task の完了を待ちながら他の request を処理したり、追加の作業を行ったりできます。

このパターンを支援するために、server は CreateTaskResult の _meta フィールドに、省略可能な io.modelcontextprotocol/model-immediate-response キーを提供できます。このキーの値は、model に即時の tool result として渡されることを意図した文字列であるべきです。 server がこのフィールドを提供しない場合、host application は独自に定義したメッセージにフォールバックできます。

このガイダンスは拘束力を持たず、特定のユースケースを考慮した暫定的なロジックです。この挙動は、将来 CreateTaskResult の一部として正式化または変更される可能性があります。

Getting Tasks

Streamable HTTP (SSE) transport では、client は tasks/get request に対する response として server によって開かれた SSE stream から、いつでも切断してかまいません。

この注記は SSE stream の具体的な使い方を規定するものではありませんが、すべての実装は既存の Streamable HTTP transport specification に引き続き準拠しなければなりません (MUST)。

requestor は、tasks/get request を送ることで task 完了をポーリングします。requestor は、ポーリング頻度を決める際に response で提供された pollInterval を尊重するべきです (SHOULD)。

requestor は、task が terminal status（completed、failed、または cancelled）に到達するか、input_required status に遭遇するまで、ポーリングを続けるべきです (SHOULD)。tasks/result を呼び出したからといって、requestor がポーリングをやめる必要があることを意味するわけではありません。tasks/result の完了を能動的に待っていない場合、requestor は引き続き tasks/get を通じて task status をポーリングするべきです (SHOULD)。

Request:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tasks/get",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "working",
    "statusMessage": "The operation is now in progress.",
    "createdAt": "2025-11-25T10:30:00Z",
    "lastUpdatedAt": "2025-11-25T10:40:00Z",
    "ttl": 30000,
    "pollInterval": 5000
  }
}

Retrieving Task Results

Streamable HTTP (SSE) transport では、client は tasks/result request に対する response として server によって開かれた SSE stream から、いつでも切断してかまいません。

この注記は SSE stream の具体的な使い方を規定するものではありませんが、すべての実装は既存の Streamable HTTP transport specification に引き続き準拠しなければなりません。

task が完了した後、operation result は tasks/result を通じて取得されます。これは task data だけを含む最初の CreateTaskResult response とは別物です。result の構造は元の request type に一致します（たとえば tools/call に対しては CallToolResult）。

完了した task の result を取得するために、requestor は tasks/result request を送れます。

tasks/result は task が terminal status に到達するまでブロックしますが、requestor は並行して tasks/get によるポーリングを続けられます。たとえば、以前の tasks/result request が失敗またはキャンセルされていて、自身が result 待ちで積極的にブロックしていない場合です。これにより、tasks/result を呼び出した後であっても、requestor は task 実行中の status 変化や progress update を監視できます。

Request:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tasks/result",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false,
    "_meta": {
      "io.modelcontextprotocol/related-task": {
        "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
      }
    }
  }
}

Task Status Notification

task status が変化したとき、receiver はその変化を requestor に知らせるために notifications/tasks/status notification を送ってもかまいません。この notification には完全な task state が含まれます。

Notification:

{
  "jsonrpc": "2.0",
  "method": "notifications/tasks/status",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "completed",
    "createdAt": "2025-11-25T10:30:00Z",
    "lastUpdatedAt": "2025-11-25T10:50:00Z",
    "ttl": 60000,
    "pollInterval": 5000
  }
}

この notification には、更新された status と statusMessage（存在する場合）を含む完全な Task オブジェクトが含まれます。これにより、requestor は追加の tasks/get request を行わなくても完全な task state にアクセスできます。

requestor は、この notification を受信することを前提にしてはなりません (MUST NOT)。これは任意機能だからです。receiver は status notification を送る義務がなく、特定の status 遷移に対してだけ送ることもできます。requestor は、status update を確実に受け取るために、tasks/get によるポーリングを継続するべきです (SHOULD)。

Listing Tasks

task の一覧を取得するために、requestor は tasks/list request を送れます。この operation はページネーションをサポートします。

Request:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tasks/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "tasks": [
      {
        "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
        "status": "working",
        "createdAt": "2025-11-25T10:30:00Z",
        "lastUpdatedAt": "2025-11-25T10:40:00Z",
        "ttl": 30000,
        "pollInterval": 5000
      },
      {
        "taskId": "abc123-def456-ghi789",
        "status": "completed",
        "createdAt": "2025-11-25T09:15:00Z",
        "lastUpdatedAt": "2025-11-25T10:40:00Z",
        "ttl": 60000
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

Cancelling Tasks

task を明示的にキャンセルするために、requestor は tasks/cancel request を送れます。

Request:

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tasks/cancel",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 6,
  "result": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "cancelled",
    "statusMessage": "The task was cancelled by request.",
    "createdAt": "2025-11-25T10:30:00Z",
    "lastUpdatedAt": "2025-11-25T10:40:00Z",
    "ttl": 30000,
    "pollInterval": 5000
  }
}

Behavior Requirements

これらの要件は、task-augmented request の受信をサポートするすべての当事者に適用されます。

Task Support and Handling

ある request type に対して task capability を宣言していない receiver は、その type の request を通常どおり処理しなければなりません (MUST)。task-augmentation metadata が存在していても、それを無視します。
ある request type に対して task capability を宣言している receiver は、非 task-augmented request に対してエラーを返し、requestor に task augmentation の使用を要求してもかまいません。

Task ID Requirements

Task ID は文字列値でなければなりません (MUST)。
Task ID は、task 作成時に receiver が生成しなければなりません (MUST)。
Task ID は、その receiver が管理するすべての task の中で一意でなければなりません (MUST)。

Task Status Lifecycle

Task は、作成時に必ず working status で開始しなければなりません (MUST)。
receiver は、task を次の有効な経路でのみ遷移させなければなりません (MUST)。
1. working からは、input_required、completed、failed、または cancelled に移ってもかまいません。
2. input_required からは、working、completed、failed、または cancelled に移ってもかまいません。
3. completed、failed、または cancelled status の task は terminal state にあり、他のどの status にも遷移してはなりません (MUST NOT)。

Task Status State Diagram:

stateDiagram-v2 [*] --> working working --> input_required working --> terminal input_required --> working input_required --> terminal terminal --> [*] note right of terminal Terminal states: • completed • failed • cancelled end note

Input Required Status

Streamable HTTP (SSE) transport では、server は response message を配信した後に SSE stream を閉じることが多く、その結果、後続の task message に使われる stream がどれかについて曖昧さが生じる可能性があります。

server は、他の response と並行して task 関連 message を client に side-channel で送るようにメッセージをキューイングすることで、これに対処できます。

server は、task polling および result retrieval の間に SSE stream をどのように管理するかについて柔軟性を持ち、client は HTTP GET stream を含む任意の SSE stream 上で message が届けられることを想定するべきです。 1 つの可能なアプローチは、tasks/result 上で SSE stream を維持することです（input_required status に関する注記を参照）。可能であれば、server は tasks/get request に対する response として SSE stream にアップグレードしないべきです。client は結果をポーリングしたい意図を示しているからです。

この注記は SSE stream の具体的な使い方を規定するものではありませんが、すべての実装は既存の Streamable HTTP transport specification に引き続き準拠しなければなりません。

task receiver が、その task を完了するために必要な message を requestor に送る必要がある場合、receiver は task を input_required status に移すべきです (SHOULD)。
receiver は、その request に io.modelcontextprotocol/related-task metadata を含めて task との関連付けを行わなければなりません (MUST)。
requestor が input_required status に遭遇した場合、requestor は先回りして tasks/result を呼び出すべきです (SHOULD)。
receiver が必要な input をすべて受け取ったとき、task は input_required status を抜けるべきです (SHOULD)（通常は working に戻ります）。

TTL and Resource Management

receiver は、すべての task response に、task が作成された時刻を示す createdAt の ISO 8601 形式タイムスタンプを含めなければなりません。
receiver は、すべての task response に、task が最後に更新された時刻を示す lastUpdatedAt の ISO 8601 形式タイムスタンプを含めなければなりません。
receiver は、要求された ttl duration を上書きしてもかまいません。
receiver は、tasks/get response に、実際の ttl duration（または無制限を示す null）を含めなければなりません。
task の ttl lifetime が経過した後、receiver は task status に関係なく、その task とその result を削除してもかまいません。
receiver は、推奨ポーリング間隔として pollInterval 値（ミリ秒）を tasks/get response に含めてもかまいません。requestor は、それが提供された場合にはこの値を尊重するべきです。

Result Retrieval

task-augmented request を受理した receiver は、response として CreateTaskResult を返さなければなりません。この result は、task を受理した後できるだけ早く返すべきです。
terminal status（completed、failed、または cancelled）にある task に対する tasks/result request を受け取ったとき、receiver は基底の request の最終 result を返さなければなりません。それが成功 result であっても JSON-RPC error であっても同様です。
それ以外の non-terminal status（working または input_required）にある task に対する tasks/result request を受け取ったとき、receiver は task が terminal status に到達するまで response をブロックしなければなりません。
terminal status にある task について、receiver は tasks/result から、基底の request が返したはずのものを正確に返さなければなりません。それが成功 result であっても JSON-RPC error であっても同様です。

task に関連するすべての request、notification、response は、その _meta フィールドに io.modelcontextprotocol/related-task キーを含めなければなりません。その値は、関連する task ID に一致する taskId を持つオブジェクトでなければなりません。
1. たとえば、task-augmented な tool call が依存する elicitation は、その tool call の task と同じ related task ID を共有しなければなりません。
tasks/get、tasks/result、および tasks/cancel operation では、request 内の taskId パラメータを、対象 task を識別する source of truth として使わなければなりません。requestor は、これらの request に io.modelcontextprotocol/related-task metadata を含めるべきではなく、receiver はそれが存在していても RPC method parameter を優先して無視しなければなりません。同様に、tasks/get、tasks/list、および tasks/cancel operation について、receiver は result message に io.modelcontextprotocol/related-task metadata を含めるべきではありません。taskId はすでに response 構造に含まれているからです。

Task Notifications

receiver は、task の status が変化したときに notifications/tasks/status notification を送ってもかまいません。
requestor は、notifications/tasks/status notification を受け取ることを前提にしてはなりません。これは任意だからです。
送信する場合、notifications/tasks/status notification には io.modelcontextprotocol/related-task metadata を含めるべきではありません。task ID はすでに notification parameter に含まれているからです。

Task Progress Notifications

task-augmented request は、progress 仕様で定義されている progress notification をサポートします。最初の request で提供された progressToken は、task lifetime を通じて有効なままです。

Task Listing

receiver は、1 回の response で返す task 数を制限するために、cursor-based pagination を使うべきです。
receiver は、さらに task が存在する場合、response に nextCursor を含めなければなりません。
requestor は cursor を opaque token として扱わなければならず、解析や変更を試みてはなりません。
ある requestor に対して tasks/get で取得可能な task は、その requestor に対して tasks/list でも取得可能でなければなりません。

Task Cancellation

receiver は、すでに terminal status（completed、failed、または cancelled）にある task に対する cancellation request を、エラーコード -32602 (Invalid params) で拒否しなければなりません。
有効な cancellation request を受け取ったとき、receiver は task 実行の停止を試みるべきであり、response を送る前に task を cancelled status に遷移させなければなりません。
task が一度キャンセルされたら、たとえ実行がその後も完了まで進んだり失敗したりしても、その task は cancelled status のままでなければなりません。
tasks/cancel operation は削除挙動を定義しません。ただし receiver は、キャンセルされた task を任意のタイミングで削除してもかまいません。キャンセル直後でも、task の ttl 期限後でも構いません。
requestor は、キャンセルされた task が特定の期間保持されることを前提にするべきではなく、必要な情報はキャンセル前に取得するべきです。

Message Flow

Basic Task Lifecycle

sequenceDiagram participant C as Client (Requestor) participant S as Server (Receiver) Note over C,S: 1. Task Creation C->>S: Request with task field (ttl) activate S S->>C: CreateTaskResult (taskId, status: working, ttl, pollInterval) deactivate S Note over C,S: 2. Task Polling C->>S: tasks/get (taskId) activate S S->>C: working deactivate S Note over S: Task processing continues... C->>S: tasks/get (taskId) activate S S->>C: working deactivate S Note over S: Task completes C->>S: tasks/get (taskId) activate S S->>C: completed deactivate S Note over C,S: 3. Result Retrieval C->>S: tasks/result (taskId) activate S S->>C: Result content deactivate S Note over C,S: 4. Cleanup Note over S: After ttl period from creation, task is cleaned up

Task-Augmented Tool Call With Elicitation

sequenceDiagram participant U as User participant LLM participant C as Client (Requestor) participant S as Server (Receiver) Note over LLM,C: LLM initiates request LLM->>C: Request operation Note over C,S: Client augments with task C->>S: tools/call (ttl: 3600000) activate S S->>C: CreateTaskResult (task-123, status: working) deactivate S Note over LLM,C: Client continues processing other requests<br/>while task executes in background LLM->>C: Request other operation C->>LLM: Other operation result Note over C,S: Client polls for status C->>S: tasks/get (task-123) activate S S->>C: working deactivate S Note over S: Server needs information from client<br/>Task moves to input_required Note over C,S: Client polls and discovers input_required C->>S: tasks/get (task-123) activate S S->>C: input_required deactivate S Note over C,S: Client opens result stream C->>S: tasks/result (task-123) activate S S->>C: elicitation/create (related-task: task-123) activate C C->>U: Prompt user for input U->>C: Provide information C->>S: elicitation response (related-task: task-123) deactivate C deactivate S Note over C,S: Client closes result stream and resumes polling Note over S: Task continues processing...<br/>Task moves back to working C->>S: tasks/get (task-123) activate S S->>C: working deactivate S Note over S: Task completes Note over C,S: Client polls and discovers completion C->>S: tasks/get (task-123) activate S S->>C: completed deactivate S Note over C,S: Client retrieves final results C->>S: tasks/result (task-123) activate S S->>C: Result content deactivate S C->>LLM: Process result Note over S: Results retained for ttl period from creation

Task-Augmented Sampling Request

sequenceDiagram participant U as User participant LLM participant C as Client (Receiver) participant S as Server (Requestor) Note over S: Server decides to initiate request Note over S,C: Server requests client operation (task-augmented) S->>C: sampling/createMessage (ttl: 3600000) activate C C->>S: CreateTaskResult (request-789, status: working) deactivate C Note over S: Server continues processing<br/>while waiting for result Note over S,C: Server polls for result S->>C: tasks/get (request-789) activate C C->>S: working deactivate C Note over C,U: Client may present request to user C->>U: Review request U->>C: Approve request Note over C,LLM: Client may involve LLM C->>LLM: Request completion LLM->>C: Return completion Note over C,U: Client may present result to user C->>U: Review result U->>C: Approve result Note over S,C: Server polls and discovers completion S->>C: tasks/get (request-789) activate C C->>S: completed deactivate C Note over S,C: Server retrieves result S->>C: tasks/result (request-789) activate C C->>S: Result content deactivate C Note over S: Server continues processing Note over C: Results retained for ttl period from creation

Task Cancellation Flow

sequenceDiagram participant C as Client (Requestor) participant S as Server (Receiver) Note over C,S: 1. Task Creation C->>S: tools/call (request ID: 42, ttl: 60000) activate S S->>C: CreateTaskResult (task-123, status: working) deactivate S Note over C,S: 2. Task Processing C->>S: tasks/get (task-123) activate S S->>C: working deactivate S Note over C,S: 3. Client Cancellation Note over C: User requests cancellation C->>S: tasks/cancel (taskId: task-123) activate S Note over S: Server stops execution (best effort) Note over S: Task moves to cancelled status S->>C: Task (status: cancelled) deactivate S Note over C: Client receives confirmation Note over S: Server may delete task at its discretion

Data Types

Task

Task は request の実行状態を表します。task state には次の内容が含まれます。

taskId: task の一意識別子
status: task 実行の現在状態
statusMessage: 現在状態を説明する省略可能な human-readable message（失敗 task のエラー詳細を含め、どの status に対しても存在しうる）
createdAt: task が作成された時刻の ISO 8601 タイムスタンプ
ttl: 作成から task が削除されうるまでのミリ秒時間
pollInterval: status チェックの間の推奨ミリ秒時間
lastUpdatedAt: task status が最後に更新された時刻の ISO 8601 タイムスタンプ

Task Status

Task は次のいずれかの状態を取れます。

working: request が現在処理中です。
input_required: receiver が requestor からの入力を必要としています。task はまだ terminal state に達していませんが、requestor は入力 request を受け取るために tasks/result を呼び出すべきです。
completed: request は正常に完了し、result が取得可能です。
failed: 関連する request は正常には完了しませんでした。tool call に限れば、tool call result の isError が true に設定されている場合もこれに含まれます。
cancelled: request は完了前にキャンセルされました。

Task Parameters

task execution で request を拡張する際には、request parameter に task フィールドが含まれます。

{
  "task": {
    "ttl": 60000
  }
}

フィールド:

ttl (number, optional): 作成時点から task を保持してほしいミリ秒 duration

task に関連するすべての request、response、notification は、_meta に io.modelcontextprotocol/related-task キーを含めなければなりません。

{
  "io.modelcontextprotocol/related-task": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

これにより、request lifecycle 全体を通じて、message がその発生元 task と関連付けられます。

tasks/get、tasks/list、および tasks/cancel operation については、requestor と receiver はこの metadata を message に含めるべきではありません。taskId はすでに message 構造に含まれているからです。 tasks/result operation では、その response にこの metadata を含めなければなりません。result 構造自体には task ID が含まれていないからです。

Error Handling

Tasks は 2 つのエラー報告機構を使います。

Protocol Errors: プロトコルレベルの問題に対する標準 JSON-RPC error
Task Execution Errors: 基底 request 実行中のエラーで、task status を通じて報告されるもの

Protocol Errors

receiver は、次の protocol error case に対して標準 JSON-RPC error を返さなければなりません。

tasks/get、tasks/result、または tasks/cancel における無効または存在しない taskId: -32602 (Invalid params)
tasks/list における無効または存在しない cursor: -32602 (Invalid params)
すでに terminal status にある task をキャンセルしようとした場合: -32602 (Invalid params)
internal error: -32603 (Internal error)

さらに receiver は、次のエラーを返してもかまいません。

receiver がその request type に task augmentation を要求しているのに、request が non-task-augmented である場合: -32600 (Invalid request)

receiver は、エラー原因を説明する情報量のある error message を提供するべきです。

Example: Task augmentation required

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32600,
    "message": "Task augmentation required for tools/call requests"
  }
}

Example: Task not found

{
  "jsonrpc": "2.0",
  "id": 70,
  "error": {
    "code": -32602,
    "message": "Failed to retrieve task: Task not found"
  }
}

Example: Task expired

{
  "jsonrpc": "2.0",
  "id": 71,
  "error": {
    "code": -32602,
    "message": "Failed to retrieve task: Task has expired"
  }
}

receiver は task を無期限に保持する必要はありません。期限切れ task を削除済みで見つからないとするエラーを返すのは、仕様に準拠した挙動です。

Example: Task cancellation rejected (already terminal)

{
  "jsonrpc": "2.0",
  "id": 74,
  "error": {
    "code": -32602,
    "message": "Cannot cancel task: already in terminal status 'completed'"
  }
}

Task Execution Errors

基底 request が正常に完了しなかった場合、task は failed status に移行します。これには、request 実行中の JSON-RPC protocol error や、tool call に限れば tool result の isError が true に設定されている場合が含まれます。tasks/get response は、失敗の診断情報を持つ statusMessage フィールドを含めるべきです。

Example: Task with execution error

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f820fe840",
    "status": "failed",
    "createdAt": "2025-11-25T10:30:00Z",
    "lastUpdatedAt": "2025-11-25T10:40:00Z",
    "ttl": 30000,
    "statusMessage": "Tool execution failed: API rate limit exceeded"
  }
}

tool call request をラップする task では、tool result の isError が true に設定されている場合、その task は failed status に到達するべきです。

tasks/result endpoint は、基底 request が返したはずのものを正確に返します。

基底 request が JSON-RPC error になった場合、tasks/result はその同じ JSON-RPC error を返さなければなりません。
request が JSON-RPC response で完了した場合、tasks/result はその result を含む成功 JSON-RPC response を返さなければなりません。

Security Considerations

Task Isolation and Access Control

Task ID は、task state と result にアクセスするための主要な仕組みです。適切な access control がなければ、task ID を推測または取得できた当事者は、機微な情報にアクセスしたり、自分が作成していない task を操作したりできる可能性があります。

認可コンテキストが提供されている場合、receiver は task をそのコンテキストに結び付けなければなりません。

コンテキスト結合は、すべての application で現実的とは限りません。MCP server の中には、単一ユーザー用ツールのように認可なしの環境で動くものや、認可をサポートしない transport を使うものがあります。このような場合、receiver はこの制約を明確に文書化するべきです。task result は、task ID を推測できる任意の requestor からアクセス可能になりうるからです。コンテキスト結合が使えない場合、receiver は推測を防ぐのに十分なエントロピーを持つ、暗号学的に安全な task ID を生成しなければなりません。また、露出時間を減らすために短めの TTL duration の使用を検討するべきです。さらに、requestor を識別できない receiver は、tasks.list capability を宣言するべきではありません。task 一覧は、task ID のエントロピーに関係なく、任意の requestor に task metadata を露出させてしまうからです。

コンテキスト結合が利用可能な場合、receiver は、同じ認可コンテキストに属さない task に対する tasks/get、tasks/result、および tasks/cancel request を拒否しなければなりません。tasks/list request については、返される task list に、requestor の認可コンテキストに関連付けられた task だけが含まれるよう保証しなければなりません。

加えて、receiver は denial-of-service や enumeration attack を防ぐために、task operation に rate limiting を実装するべきです。

Resource Management

receiver は次のことを行うべきです。
1. requestor ごとの同時 task 数に上限を設ける
2. リソースを無期限に保持しないよう、ttl duration の最大値を設ける
3. 期限切れ task を速やかにクリーンアップしてリソースを解放する
4. サポートする最大 ttl duration を文書化する
5. requestor ごとの最大同時 task 数を文書化する
6. リソース使用量の監視とアラートを実装する

Audit and Logging

receiver は次のことを行うべきです。
1. 監査目的のために、task 作成、完了、取得イベントをログに記録する
2. 利用可能な場合は auth context をログに含める
3. 不審なパターン（たとえば多数の task lookup 失敗や過剰なポーリング）を監視する
requestor は次のことを行うべきです。
1. デバッグおよび監査のために task lifecycle event をログに記録する
2. task ID とそれに関連する operation を追跡する

Tasks

Documentation Index

Definitions

User Interaction Model

Capabilities

Server Capabilities

Client Capabilities

Capability Negotiation

Tool-Level Negotiation

Protocol Messages

Creating Tasks

Getting Tasks

Retrieving Task Results

Task Status Notification

Listing Tasks

Cancelling Tasks

Behavior Requirements

Task Support and Handling

Task ID Requirements

Task Status Lifecycle

Input Required Status

TTL and Resource Management

Result Retrieval

Associating Task-Related Messages

Task Notifications

Task Progress Notifications

Task Listing

Task Cancellation

Message Flow

Basic Task Lifecycle

Task-Augmented Tool Call With Elicitation

Task-Augmented Sampling Request

Task Cancellation Flow

Data Types

Task

Task Status

Task Parameters

Related Task Metadata

Error Handling

Protocol Errors

Task Execution Errors

Security Considerations

Task Isolation and Access Control

Resource Management

Audit and Logging