Tasks changedspecification/2025-11-25/basic/utilities/tasks
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 20:07 UTC.
Upstream edited
Recorded here
Lines+36added
Lines−38removed
From line
1
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits3to this page, all time
The whole hunk
from line 1, old and new numbered
/
from line 1
11# Tasks
22
3<div id="enable-section-numbers" />
3> [!NOTE]
4>
5> Tasks were introduced in version 2025-11-25 of the MCP specification and are currently considered **experimental**.
6> The design and behavior of tasks may evolve in future protocol versions.
47
5<Note>
6 Tasks were introduced in version 2025-11-25 of the MCP specification and are currently considered **experimental**.
7 The design and behavior of tasks may evolve in future protocol versions.
8</Note>
9
108The Model Context Protocol (MCP) allows requestors — which can be either clients or servers, depending on the direction of communication — to augment their requests with **tasks**. Tasks are durable state machines that carry information about the underlying execution state of the request they wrap, and are intended for requestor polling and deferred result retrieval. Each task is uniquely identifiable by a receiver-generated **task ID**.
119
1210Tasks are useful for representing expensive computations and batch processing requests, and integrate seamlessly with external job APIs.
from line 162
164162
165163When a receiver accepts a task-augmented request, it returns a [`CreateTaskResult`](/specification/2025-11-25/schema#createtaskresult) containing task data. The response does not include the actual operation result. The actual result (e.g., tool result for `tools/call`) becomes available only through `tasks/result` after the task completes.
166164
167<Note>
168 When a task is created in response to a `tools/call` request, host applications may wish to return control to the model while the task is executing. This allows the model to continue processing other requests or perform additional work while waiting for the task to complete.
165> [!NOTE]
166>
167> When a task is created in response to a `tools/call` request, host applications may wish to return control to the model while the task is executing. This allows the model to continue processing other requests or perform additional work while waiting for the task to complete.
168>
169> To support this pattern, servers can provide an optional `io.modelcontextprotocol/model-immediate-response` key in the `_meta` field of the `CreateTaskResult`. The value of this key should be a string intended to be passed as an immediate tool result to the model.
170> If a server does not provide this field, the host application can fall back to its own predefined message.
171>
172> This guidance is non-binding and is provisional logic intended to account for the specific use case. This behavior may be formalized or modified as part of `CreateTaskResult` in future protocol versions.
169173
170 To support this pattern, servers can provide an optional `io.modelcontextprotocol/model-immediate-response` key in the `_meta` field of the `CreateTaskResult`. The value of this key should be a string intended to be passed as an immediate tool result to the model.
171 If a server does not provide this field, the host application can fall back to its own predefined message.
172
173 This guidance is non-binding and is provisional logic intended to account for the specific use case. This behavior may be formalized or modified as part of `CreateTaskResult` in future protocol versions.
174</Note>
175
176174### Getting Tasks
177175
178<Note>
179 In the Streamable HTTP (SSE) transport, clients **MAY** disconnect from an SSE stream opened by the server in response to a `tasks/get` request at any time.
176> [!NOTE]
177>
178> In the Streamable HTTP (SSE) transport, clients **MAY** disconnect from an SSE stream opened by the server in response to a `tasks/get` request at any time.
179>
180> While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
180181
181 While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
182</Note>
183
184182Requestors poll for task completion by sending [`tasks/get`](/specification/2025-11-25/schema#tasks%2Fget) requests.
185183Requestors **SHOULD** respect the `pollInterval` provided in responses when determining polling frequency.
186184
from line 217
219217
220218### Retrieving Task Results
221219
222<Note>
223 In the Streamable HTTP (SSE) transport, clients **MAY** disconnect from an SSE stream opened by the server in response to a `tasks/result` request at any time.
220> [!NOTE]
221>
222> In the Streamable HTTP (SSE) transport, clients **MAY** disconnect from an SSE stream opened by the server in response to a `tasks/result` request at any time.
223>
224> While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
224225
225 While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
226</Note>
227
228226After a task completes the operation result is retrieved via [`tasks/result`](/specification/2025-11-25/schema#tasks%2Fresult). This is distinct from the initial `CreateTaskResult` response, which contains only task data. The result structure matches the original request type (e.g., `CallToolResult` for `tools/call`).
229227
230228To retrieve the result of a completed task, requestors can send a `tasks/result` request:
from line 418
420418
421419### Input Required Status
422420
423<Note>
424 With the Streamable HTTP (SSE) transport, servers often close SSE streams after delivering a response message, which can lead to ambiguity regarding the stream used for subsequent task messages.
421> [!NOTE]
422>
423> With the Streamable HTTP (SSE) transport, servers often close SSE streams after delivering a response message, which can lead to ambiguity regarding the stream used for subsequent task messages.
424>
425> Servers can handle this by enqueueing messages to the client to side-channel task-related messages alongside other responses.
426>
427> Servers have flexibility in how they manage SSE streams during task polling and result retrieval, and clients **SHOULD** expect messages to be delivered on any SSE stream, including the HTTP GET stream.
428> One possible approach is maintaining an SSE stream on `tasks/result` (see notes on the `input_required` status).
429> Where possible, servers **SHOULD NOT** upgrade to an SSE stream in response to a `tasks/get` request, as the client has indicated it wishes to poll for a result.
430>
431> While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
425432
426 Servers can handle this by enqueueing messages to the client to side-channel task-related messages alongside other responses.
427
428 Servers have flexibility in how they manage SSE streams during task polling and result retrieval, and clients **SHOULD** expect messages to be delivered on any SSE stream, including the HTTP GET stream.
429 One possible approach is maintaining an SSE stream on `tasks/result` (see notes on the `input_required` status).
430 Where possible, servers **SHOULD NOT** upgrade to an SSE stream in response to a `tasks/get` request, as the client has indicated it wishes to poll for a result.
431
432 While this note is not prescriptive regarding the specific usage of SSE streams, all implementations **MUST** continue to comply with the existing [Streamable HTTP transport specification](../transports#sending-messages-to-the-server).
433</Note>
434
4354331. When the task receiver has messages for the requestor that are necessary to complete the task, the receiver **SHOULD** move the task to the `input_required` status.
4364342. The receiver **MUST** include the `io.modelcontextprotocol/related-task` metadata in the request to associate it with the task.
4374353. When the requestor encounters the `input_required` status, it **SHOULD** preemptively call `tasks/result`.
from line 801
803801}
804802```
805803
806<Note>
807 Receivers are not required to retain tasks indefinitely. It is compliant behavior for a receiver to return an error stating the task cannot be found if it has purged an expired task.
808</Note>
804> [!NOTE]
805>
806> Receivers are not required to retain tasks indefinitely. It is compliant behavior for a receiver to return an error stating the task cannot be found if it has purged an expired task.
809807
810808**Example: Task cancellation rejected (already terminal)**
811809
No line in this hunk matches that.