MCP Tasks let a slow tool call return a durable handle instead of blocking, so work that takes minutes survives timeouts, disconnects and restarts. What most guides still do not say is that the design changed materially on 28 July 2026. Tasks left the experimental protocol core, became the io.modelcontextprotocol/tasks extension, and flipped from client-requested to server-directed. If you built against the November 2025 version, most of what you wrote has moved.
What actually changed in MCP Tasks on 28 July 2026?
The maintainers describe it in one sentence in the 2026-07-28 release notes: Tasks move out of the experimental core and into the tasks extension, with a poll-based tasks/get and a new tasks/update, and change notifications move from the old HTTP GET endpoint to a single subscriptions/listen stream. That sentence hides four separate breaks.
- Who decides. In the 2025 design the requestor asked for a task by adding a task object with a ttl to the request params, and each tool advertised whether task augmentation was forbidden, optional or required. In the extension the server decides, per request. A client declares support once, in the extensions field of the capabilities it sends in every request's _meta, and then has to handle whichever result shape comes back. The Tasks documentation is blunt about the intent: no per-tool warmup, no per-request flag.
- What comes back. A task response is identified by resultType: "task" and carries a taskId, an initial status, a ttlMs and a suggested pollIntervalMs. The task must be durably created before that response is sent, which is a real constraint on your server, not a nicety.
- How you collect the answer. The old design had a blocking tasks/result call that held the response open until the task reached a terminal state. The extension has three methods and no blocking one: tasks/get, tasks/update and tasks/cancel. Polling is the default.
- How input works mid-flight. When a task needs a confirmation it moves to input_required and the tasks/get response carries an inputRequests map. The client answers with tasks/update. No second connection, no unsolicited server-to-client messages.
The five statuses survived the rewrite: working, input_required, completed, failed and cancelled, with the last three terminal. Cancellation is cooperative, which is worth reading twice. tasks/cancel records an intent. The server acknowledges it and may still finish the work.
Why did the design flip from requestor-driven to server-directed?
Because sessions are gone, and almost every commentary on Tasks treats that as a separate story. It is the same story. The headline of the 2026-07-28 release is the stateless core: the initialize and initialized handshake and the Mcp-Session-Id header were retired, so any request can land on any server instance behind a plain round-robin load balancer.
A blocking tasks/result cannot survive that. Holding a response open until a job finishes is session state wearing a different hat: it pins a client to one process for the duration of the work, which is precisely what the release set out to remove. Once you delete the held-open response, polling is not a design preference. It is the only mechanism left that works when consecutive requests reach different instances. The same logic explains why the per-tool taskSupport declaration disappeared: it lived in a tools/list response that clients are now encouraged to cache with a ttlMs, so it was no longer a reliable place to negotiate anything.
There is a second consequence that is easy to miss and expensive to discover late. MCP now has two different input_required paths. Multi Round-Trip Requests (SEP-2322) return resultType: "input_required" and the client retries the original call with the answers attached in inputResponses. Tasks return the status input_required against a handle, and the client answers with tasks/update. Same words, different control flow, and a different failure cost: MRTR discards the partial work and replays the call, while a task keeps the computation alive on the server. If your tool spends ninety seconds building something before it asks a human to approve it, that distinction is the difference between one run and two.
How much does polling actually cost you?
The roadmap phrase to notice is that server-initiated events are meant to stop clients being "left polling for results". Here is the arithmetic behind that, with the assumptions stated so you can substitute your own.
Assume a mid-sized workload: 40 long-running jobs per working day, averaging 12 minutes each, and a server that suggests a pollIntervalMs of 5000. Twelve minutes is 720 seconds, so each job takes 144 polls. That is 5,760 polls a day, or roughly 126,700 over a 22-day working month. Each of those is a full HTTP request under the stateless core, self-describing, carrying its own capabilities in _meta and its own Mcp-Method and Mcp-Name headers, and each one gets its own authorization check.
The same month delivered by push would be about 880 notifications, one per job plus a margin. That is a reduction of roughly 99.3 percent in control-plane traffic to deliver exactly the same information. Put differently: today the protocol spends 144 authenticated round trips to communicate one bit, namely whether the job is done.
Two honest caveats. Polls do not have to cost model tokens, because a well-built client loop handles them without a round trip through the LLM, so this is an infrastructure bill and not an inference bill. And 126,700 requests a month is not a large number for most hosting. The cost shows up at the edges: per-request pricing, rate limiters that were sized for human-paced traffic, token introspection on every call, and log volume that makes the useful events hard to find. Our post on running MCP in production covers where those bills actually land.
What will webhooks and channels change?
On 22 August 2026 the Core Maintainers published a new MCP roadmap organised into five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise-ready security, improved primitives, and SDK developer experience. Tasks sits in the first one.
The work named there is server-initiated events, specifically webhooks and channels, led by the Triggers and Events Working Group, plus a composition review across the Agents, Transports and Triggers and Events groups, plus maturing the Tasks extension so it can move into the specification. Read that last clause carefully, because it is the part with practical consequences: Tasks is not in the specification today. It is an extension the maintainers intend to promote, and the roadmap covers six to twelve months.
There is already a partial answer in the current spec. Servers can push notifications/tasks, and clients opt into them through subscriptions/listen, a long-lived stream where the client names exactly which notification types it wants and the server must not send anything it did not ask for. Each notification carries the full task state, so there is no extra tasks/get round trip. The documentation still says polling is the default, which is the honest position while client support is thin.
Is the Tasks extension safe to build on today?
For servers, yes, with one design rule. For clients, check before you assume. The evidence points both ways and it is worth laying out rather than picking a side.
- In favour: SEP-2663 has reached Final status on the Extensions Track. Tasks was contributed by AWS, which names Amazon Bedrock AgentCore as where the new spec runs, per the vendor statements in the release post, and Microsoft Foundry and FastMCP 4.0 both named background-task support at launch. This is not a proposal with no implementations behind it.
- Against: Tasks is an extension and not part of the specification, which is exactly what the roadmap proposes to change. The ext-tasks repository still labels its own status experimental on GitHub. And the community-maintained extension support matrix tracks MCP Apps, OAuth Client Credentials and Enterprise-Managed Authorization. Tasks is not on it at all, for any client.
That absence matters more than it looks. Extensions are opt-in from both sides: a server must verify the client declared the extension before returning a task, and must never return one to a client that did not. So a server that can only work asynchronously will simply fail against a large part of the ecosystem. The design rule follows directly: build the synchronous path first and return a task as an upgrade when the client says it can take one.
Where does long-running work actually show up in a Dutch SME?
For a company of 20 to 50 people the honest list is short, and none of it is exotic. Overnight extraction of a batch of purchase invoices. A nightly sync of enriched records into Exact Online or AFAS. A bulk reclassification of a document archive after someone changes the chart of accounts. A monthly report that reads three systems and takes eleven minutes to assemble. In each case a synchronous tool call is the wrong shape, and today most teams solve it by having the agent kick off a job and then hand the user a link to check later, which is a hand-rolled task with none of the durability guarantees.
The fourth case is the interesting one: any step where a person must approve before the automation continues. input_required is the protocol's version of a control your finance team already runs. We wrote about the four-eyes principle, audit trails and idempotency as the three things that decide whether a finance automation is auditable, and Tasks is the first time MCP has offered a native place to put the first of them. The task holds the work, the person approves, the run continues on the same handle, and the taskId gives your audit trail something to reference.
For the smallest band, 1 to 10 people, the useful answer is usually no. If your automation is one n8n workflow calling one API, you have a queue already and adding a protocol extension buys you nothing. Tasks earns its complexity when several clients call the same server, or when a job outlives the session that started it. That threshold, not company size, is the trigger.
What we would build today
A duration-based rule, applied per tool rather than per server:
- Under about ten seconds: a plain synchronous tools/call. Do not reach for Tasks.
- Ten seconds to roughly two minutes: stay synchronous and emit progress notifications against the original request. Most transport intermediaries tolerate this; few tolerate much more.
- Minutes to hours, or anything that must survive a client restart: Tasks, with a durable store behind them. Task state cannot live in memory tied to a connection, because the whole point is that the connection goes away.
- Anything gated on a human decision: Tasks, regardless of how fast the compute is. It is the only path that keeps the work alive while somebody thinks about it.
Two implementation notes that will save you a bad week. Give task creation an idempotency key derived from the request, because a client that times out and retries will otherwise start a second job you are now paying for twice. And bind every taskId to the authorization context that created it, so tasks/get, tasks/update and tasks/cancel fail as if the task does not exist for anyone else. A taskId is a capability handle, and treating it as a plain identifier is how a multi-tenant server leaks results between customers.
The wider point for anyone buying rather than building: ask a vendor which spec version their MCP server speaks and whether their client declares the tasks extension. Those two answers tell you more about whether an integration will survive next year than any feature list. If you are weighing up what a working agent integration involves, our page on AI agent development sets out how we scope one, and what an AI project costs covers the budget side.
