From Experimental Core to an Official Extension
The MCP specification finalized on July 28, 2026 pulls Tasks out of the experimental core it occupied since 2025-11-25 and promotes it to a standalone extension, io.modelcontextprotocol/tasks. A server can now answer a tools/call with a task handle instead of an immediate result, and the client drives progress forward with three methods: tasks/get, tasks/update, and tasks/cancel. Because the same release removes the session handshake in favor of a stateless core, tasks/list is gone entirely — there is no safe way to scope a task list without a session to scope it to.
Separating Reads From Writes
The new spec splits status reads (tasks/get) from status writes (tasks/update). Keeping the read path idempotent and cacheable means polling the same taskId repeatedly does not scale server load linearly with poll count. Notifications were tidied up too: instead of a per-event stream, clients get a single subscriptions/listen stream and opt into only the subscriptions they need.
Cancellation Is Cooperative, Not a Guarantee
Sending tasks/cancel gets an immediate empty-result acknowledgment from the server, but that only means the cancellation intent was received — not that the task stops right away. A task can still land on a terminal status other than cancelled. Treat a cancel call as confirmed cancellation and retry the same operation, and the original task can complete late, running any side effects twice.
From Implementation to Operations: An MCP Tasks Polling Checklist
Before handing a long-running tool call off to a task handle, pin the operating targets to numbers. A reasonable starting point is a 3-5 second poll interval, a 10-minute maximum lifetime per task, and a retry cap of 5 on tasks/get failures. Treat these as circuit-breaker thresholds for the Tasks infrastructure itself, separate from whatever SLA the underlying tool carries.
The most common failure is designing around tasks/list as if it still existed. With list queries gone from the spec, auditing in-flight tasks or hunting down zombie tasks depends entirely on the server logging taskId, status transitions, and creation time on its own. Without that log, you cannot even tell how many tasks are still open after a deploy.
The second failure is mistaking cooperative cancellation for confirmed cancellation. After a tasks/cancel response comes back, hold off on any retry with side effects until tasks/get confirms the final state, and decide upfront — as an explicit policy, not an afterthought — whether to keep or discard the result if the task ultimately completes anyway.
Pre-deploy scenario tests need to cover four cases: normal completion, timeout, delayed completion after a cooperative cancel, and task loss during a server restart. Standardize log fields — taskId, status, poll count, elapsed time — so they don't fragment by tool, and mask any PII embedded in task parameters before it hits the log store.
Design polling backoff as exponential, not fixed-interval. Starting at 3 seconds and doubling on each failure, capped at 60 seconds, keeps tasks/get traffic from spiking on the server side during busy windows. Clients that have subscriptions/listen enabled should widen their polling interval accordingly instead of double-checking the same state two ways.
If any client was built against the experimental 2025-11-25 shape, the new deprecation policy's minimum 12-month window is the runway to strip out tasks/list-dependent code. All four Tier 1 SDKs support the new spec immediately, so keep a separate migration log — the failure types and days-to-complete from this cutover become the baseline for the next extension migration.
In weekly review, track three numbers: average poll count per task, the share of tasks that end in timeout, and how many delayed completions follow a cancel. A rising poll count signals either too tight a backoff cap or growing latency in the underlying tool — log the two causes separately from the code-change log, or the next review has to re-diagnose them from scratch.
Quick-Reference Checklist
As MCP Tasks moves from an experimental extension to the official spec, long-running tool calls can no longer be designed around holding an open connection. Pin numbers first — a 3-5 second poll interval, a 60-second backoff cap, a retry limit of 5 — for the tasks/get, tasks/update, and tasks/cancel trio, and fill the gap left by tasks/list with your own status log. Do that, and the spec's premise that cancellation is cooperative holds up in production too.
References
The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog