Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeDocsModel Context Protocol 20 Oct 2026
One change · mcp

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 22 Oct 2026 20:37 UTC.

Upstream edited
Recorded here
Lines+4added
Lines−4removed
From line 177 where the diff opens
First seen 26 Aug 2026 this site's first read of the page
Recorded edits4to this page, all time

The whole hunk

from line 177, old and new numbered
/
lines
from line 177
177177>
178178> 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.
179179>
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).
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](/specification/2025-11-25/basic/transports.md#sending-messages-to-the-server).
181181 
182182Requestors poll for task completion by sending [`tasks/get`](/specification/2025-11-25/schema#tasks%2Fget) requests.
183183Requestors **SHOULD** respect the `pollInterval` provided in responses when determining polling frequency.
from line 221
221221>
222222> 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.
223223>
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).
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](/specification/2025-11-25/basic/transports.md#sending-messages-to-the-server).
225225 
226226After 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`).
227227 
from line 428
428428> One possible approach is maintaining an SSE stream on `tasks/result` (see notes on the `input_required` status).
429429> 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.
430430>
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).
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](/specification/2025-11-25/basic/transports.md#sending-messages-to-the-server).
432432 
4334331. 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.
4344342. The receiver **MUST** include the `io.modelcontextprotocol/related-task` metadata in the request to associate it with the task.
from line 466
466466 
467467### Task Progress Notifications
468468 
469Task-augmented requests support progress notifications as defined in the [progress](./progress) specification. The `progressToken` provided in the initial request remains valid throughout the task lifetime.
469Task-augmented requests support progress notifications as defined in the [progress](/specification/2025-11-25/basic/utilities/progress.md) specification. The `progressToken` provided in the initial request remains valid throughout the task lifetime.
470470 
471471### Task Listing
472472 
Feedback