# The MCP Tasks Extension Vikram Vaswani, Melonfire | MLOps Community | 21:31 Source: https://www.youtube.com/watch?v=dSoXxTqHJv0 Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks. Page: https://mlopstalks.com/talks/the-mcp-tasks-extension Published: 2026-08-19 Tags: mcp, workflows ## TL;DR - MCP Tasks handle work that cannot finish in one synchronous request, such as batch exports, model training, and multi-step workflows. - The July 28, 2026 Tasks extension simplifies capability negotiation, removes blocking result calls, and returns completed results directly from task/get. - The new extension is not backward compatible, so servers supporting the earlier version need to provide their own compatibility layer. ## Summary Vikram Vaswani explains why synchronous Model Context Protocol requests are a poor fit for long-running work. Batch migrations, report generation, model training, and multi-step agent workflows may need progress checks, cancellation, or input from a user while they run. The earlier Tasks design supported these cases, but it required capability checks in several places, used a blocking task/result call for user input, and exposed a task/list operation with a possible access-control problem. The July 28, 2026 update moves Tasks into its own extension. The client declares support, while the server decides whether to use a task. Clients poll with task/get, receive input-required status through an ordinary response, send answers with task/update, and get the final result directly when the task is completed. A live demo shows report generation, polling, cancellation, blocking behavior without task support, and the error returned by the removed result call. Vaswani is clear that the design may change again. ## Key ideas ### Synchronous MCP calls do not fit work that takes minutes [01:59](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=119s) Vaswani starts with MCP's usual request-response model. It works well for database queries, API calls, and file reads that usually finish in under a second. It becomes awkward for batch migrations, batch exports, model training, and multi-step workflows that need to wait, think, and act. A synchronous connection stays open without progress reporting or cancellation. The server also cannot pause to ask a follow-up question. Before Tasks, each server had to invent its own pattern for this kind of work. ### The earlier Tasks design allowed either side to create a task [03:03](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=183s) Tasks first appeared in the 11/25 specification as part of the core protocol. The design was symmetric: either the client or server could be the requester or receiver, and either side could create or execute a task. This meant Tasks could cover tool calls as well as server-initiated operations such as sampling requests or requests for user input. The earlier version defined four methods: task/get, task/result, task/cancel, and task/list. ### The earlier lifecycle required several capability checks and a blocking input step [04:14](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=254s) Before starting a task in the earlier design, the client had to check server support for tool calls, server support for Tasks in tool calls, support declared by the individual tool, and support for list and cancel operations. A tool call then returned a task ID with a working status, and the client repeatedly polled task/get. If the server needed user input, the status changed to input-required. The client called task/result, kept that connection open, received an elicitation request, and sent the answer back over the same connection before polling resumed. ### The July 28 update moves Tasks into a separate extension [07:43](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=463s) Vaswani identifies three problems in the earlier design: capability negotiation happened at three layers, task/result was a blocking call, and task/list could potentially expose every task running on a server rather than only tasks belonging to the requesting client. The new design removes Tasks from the core specification and places it in the io.modelcontextprotocol/tasks extension. There is now one capability check. The client declares that it can handle Tasks, while the server decides whether a task should be used. The change breaks compatibility with the earlier version. ### The new lifecycle uses ordinary requests for input and returns results from task/get [08:55](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=535s) The updated lifecycle keeps the initial task call and polling pattern. When the server needs user input, task/get reports input-required instead of requiring a blocking task/result request. The client sends its response with task/update, and the task returns to working. Once the task is completed, the result appears directly in the task/get response. The separate task/result call is gone. Vaswani says the shorter lifecycle fits the stateless direction of the newer MCP protocol. ### The new methods separate protocol errors from errors inside completed work [11:09](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=669s) The updated extension defines task/get for polling and retrieving the final result, task/update for answering a server request, and task/cancel for stopping an in-progress task. Vaswani distinguishes a protocol failure from a problem reported by the task itself. An invalid task ID or unsupported polling operation can cause the task protocol to fail. A bad file path or downstream API error can leave the task marked completed while carrying the business error in its result. ### The demo shows task support, polling, cancellation, and fallback behavior [12:54](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=774s) In the demo, the server and client advertise Tasks support during capability negotiation. The available generate report tool returns immediately with a task ID and working status. Repeated task/get calls eventually return completed status and the generated report in the same response. Vaswani then starts another report and cancels it, while noting that cancellation is not guaranteed and depends on the server. A client without Tasks support causes the tool call to block. An older protocol client also blocks, and its old result call returns an error because that method was removed. ### Servers need a compatibility shim for the earlier version [19:44](https://www.youtube.com/watch?v=dSoXxTqHJv0&t=1184s) Vaswani's closing points are that the new design is smaller, stateless, and more secure because it removes task/list. It also separates reading task state from writing updates. There is no backward compatibility with the earlier experimental design. A server that needs to support those clients must add a shim itself. He expects the extension to keep changing because extensions progress independently from the main specification, and he does not present this version as final. ## Notable quotes - "The baseline model in MCP is that it's synchronous." (01:59) - "Before tasks existed, really you were on your own. Everyone created their own solution for this." (02:42) - "There's no longer an open connection which is blocking. It's just a normal request response." (09:40) - "The cancellation is not guaranteed. It's actually up to the server to define how the cancellation is done." (16:37) - "I suspect this isn't the final shape of this work." (20:20) ## Tools & references mentioned - Model Context Protocol - MCP - MCP Tasks - Melonfire - Agentic AI Foundation ## Who should watch - You are implementing MCP tools that can run longer than a normal request and need polling, cancellation, or user input. - Your server still follows the earlier Tasks design and you need to understand the compatibility break in the July 28, 2026 update. - You want to see the request flow in practice, including the behavior of clients and servers that do not advertise Tasks support. ## Related talks - [Stateless, Yet Durable: MCP Tasks v2](https://mlopstalks.com/talks/stateless-yet-durable-mcp-tasks-v2) (Cornelia Davis, Temporal, 26:23) - [MCP-Enabled Agents](https://mlopstalks.com/talks/mcp-enabled-agents) (Valdimar Eggertsson, Snjallgögn (Smart Data inc.) & Sophia Skowronski, Breckinridge Capital Advisors & Arthur Coleman, Online Matters & Tamese Salai, 57:54) - [Events Notifications in MCP](https://mlopstalks.com/talks/events-notifications-in-mcp) (Aman Singh, Microsoft, 19:30) - [Tool Calling](https://mlopstalks.com/talks/tool-calling) (Alex Salazar, Arcade.dev & Nishikant Dhanuka, Prosus Group & Luciana Ledesma, MeaningStack, 40:22) - [MCP 2.0: What Changes, What Breaks, and What You Need to Do About It](https://mlopstalks.com/talks/mcp-2-0-what-changes-what-breaks-and-what-you-need-to-do-about-it) (Mateo Torres, Arcade.dev, 21:47)