MCP Added a Tasks Extension for Long Jobs. Should Your Bot Use It Yet?

The short answer: adopt Tasks only if a call already blocks too long

If your bot's tool calls return promptly and your host can already verify their results, you may not need Tasks. Consider the extension when a tool such as a report generator or build job runs long enough that keeping one request open is awkward, and when both the client and server actually support the 2026-07-28 Tasks extension.

The extension does not turn every MCP call into a background job. A client advertises io.modelcontextprotocol/tasks in its per-request capabilities; the server chooses whether a particular tools/call returns a normal result or a task handle. Keep an existing, reliable background-job pattern if replacing it would add more complexity than the interoperable task lifecycle saves.

Sources: Tasks - MCP Tasks Extension (2026-07-28).

What the 2026-07-28 spec actually shipped

The July 2026 MCP revision made the core protocol stateless and moved the earlier experimental Tasks design into an opt-in extension. The new wire contract matters: tasks/list and the blocking tasks/result method from the 2025-11-25 experiment are gone. The 2026-07-28 extension uses tasks/get for polling and final results, tasks/update for client input during execution, and tasks/cancel to request cancellation.

When a server elects to defer a supported tool call, it responds with resultType=task and a taskId instead of the tool's final result. The server must durably create that task before returning the handle, so an immediate tasks/get for the ID can resolve. The client should persist the ID if it needs to resume polling after a restart.

Stateless core requests do not mean that a task's execution state disappears or must live in one particular database. The server must retain the task for the advertised lifecycle and authorize each task-related request. Over Streamable HTTP, task operations carry the task ID in the Mcp-Name header so intermediaries can route them to the right task owner when needed.

Sources: Key Changes - Model Context Protocol, Tasks - MCP Tasks Extension (2026-07-28).

How the call-now, fetch-later cycle actually works

The current extension's basic cycle is call, receive a task handle, then poll tasks/get. A working response can include pollIntervalMs, which clients should respect. Once status is completed, the tasks/get response includes the underlying request's result. If execution failed with a JSON-RPC error, status is failed and the response includes that error. There is no separate tasks/result fetch in this revision.

A tool result with isError: true is still a completed task under the current specification, because the underlying tools/call returned a result rather than a JSON-RPC error. An application must inspect both the task status and the result payload. Treating every completed status as a successful business outcome would hide ordinary tool failures.

If the server needs input mid-flight, tasks/get reports input_required with outstanding inputRequests. The client can answer those requests through tasks/update and continue observing the task. This is distinct from the older tasks/result blocking flow and from a fresh retry of the original tool call. A request to tasks/cancel signals intent; acknowledgement does not guarantee the server stopped work.

Sources: Tasks - MCP Tasks Extension (2026-07-28).

Worked example: a bot that kicks off a 20-minute report job (illustrative)

Illustrative case: a bot asks an MCP report tool to produce a 20-minute analytics export. Its client advertises Tasks support. The server chooses a task response, durably records the work and returns a taskId with status working. The bot can preserve that ID in its run record and let other work proceed while an orchestrator checks tasks/get at or after the suggested poll interval.

Suppose the report needs a missing date range. The next tasks/get may return input_required with a keyed request. The client should present that request through the same trust and consent model it uses for ordinary user input, then send the answer via tasks/update. It should deduplicate the request key across polls so the user is not asked twice for the same answer.

When tasks/get eventually reports completed, the final result is already in that response. The bot checks the report's identifier, file availability and expected date range before declaring its own task done. If status is failed, it records the JSON-RPC error. If status is completed but the tool result says isError: true, it records that tool-level failure instead. This example describes a design, not a measured BotBento job.

Sources: Tasks - MCP Tasks Extension (2026-07-28).

What to check before you wire this in

Check the exact extension support in both your client's SDK and the server you intend to call; support for the 2026-07-28 core protocol alone does not prove support for every optional extension. The official release said its Tier 1 SDKs spoke the new core revision, but extension APIs and versions still need a real interoperability test for your pair.

Make the task lifecycle visible in your run record: taskId, latest status, poll interval, last observation and verified final result. A server may adjust ttlMs over the task's life and may fail or delete a task after its TTL expires. Persist the task ID and decide what your bot will do if it loses the handle or the server no longer recognizes it.

Use bounded polling rather than repeatedly spending model turns on tasks/get. The specification provides pollIntervalMs guidance and may permit rate limits for clients that poll too often. Optional notifications/tasks can supplement polling through subscriptions/listen, but your client must still handle missed or unavailable notifications.

Sources: Tasks - MCP Tasks Extension (2026-07-28), The 2026-07-28 Specification.

Failure paths the spec doesn't fully close yet

A task handle is not an exactly-once receipt for the underlying side effect. If a client loses the response before it receives the taskId, blindly repeating the original tool call could create another job. Give expensive or mutating work an application-level idempotency key or reconciliation path where your service supports one; the Tasks extension does not itself promise duplicate suppression.

Cancellation is cooperative. A successful tasks/cancel acknowledgement may precede the server's decision to stop and the job may finish first. Do not tell a user that a deployment or report was rolled back solely because the cancellation request was accepted. Observe the eventual state or use the operation's own rollback evidence.

Finally, read the returned result rather than just the terminal status. Correction, 2026-10-07: an earlier version mixed the 2025-11-25 experimental proposal with the current extension, told readers to call removed tasks/result, treated all failed tool results as failed task states, and described old SDK beta and roadmap details as current. This version follows the published 2026-07-28 Tasks extension.

Sources: Tasks - MCP Tasks Extension (2026-07-28).