# The MCP Tasks Extension

## Executive summary

The session details the evolution of the MCP Tasks Extension protocol, designed for orchestrating complex, asynchronous workflows that cannot be completed in a single synchronous request. The speaker compares the older 1.120 specification with the modern 1.720 spec, highlighting major architectural improvements including statelessness, enhanced security, and simplified communication paths to better support multi-agent systems and durable execution.

## Key takeaways

- Asynchronous Workflow Handling: The Task Protocol allows for long-running operations (e.g., batch migrations, model training) by introducing a non-blocking task ID and polling mechanism, moving beyond the limitations of synchronous client-server calls.
- Protocol Simplification and Security: The new 1.720 specification significantly reduces complexity by consolidating capability checks (from three layers to one) and eliminating the insecure `task/list` method, which previously risked exposing all running tasks on the server.
- Improved Interaction Model: The new protocol replaces the blocking `tasks/result` call for user input with a non-blocking flow. If the server requires input, it changes the status to 'input required,' and the client uses the dedicated `tasks/update` method to send the response.
- Statelessness and Reliability: The updated approach is more amenable to stateless architectures, which aligns with modern best practices for scalable service design. The result of a completed task now comes directly in the `tasks/get` response.

## Technical details

- MCP Task Protocol Overview: The protocol addresses the limitation of MCP's baseline synchronous model (Client sends request -> Server returns result) when dealing with long-running, multi-step workflows.
- Version Comparison: 1.120 vs. 1.720: The older version required three layers of capability negotiation (server support, tool support, operation level). The new 1.720 spec simplifies this to a single capability check and separates tasks into its own extension (`under io.model context protocol/tasks`).
- Key Methods (1.720 Spec): The core methods are: `tasks/get` (for polling status and retrieving final results), `tasks/update` (non-blocking response submission when input is required), and `tasks/cancel` (to terminate an in-progress task).
- Error Handling Separation: The new specification separates protocol failures (e.g., bad Task ID) from business logic errors (e.g., bad file path), allowing the task to report an error while still being considered 'completed.'

## Practical implications

- Build engineers can design more robust CI/CD pipelines and agentic workflows that handle long-running, stateful tasks without relying on brittle synchronous connections.
- The stateless nature of the new protocol makes it ideal for distributed build systems and microservices architecture.
- Implementing this requires adopting the 1.720 specification to benefit from security improvements (e.g., removal of `task/list`) and simplified communication.

## Topics

MCP Protocol, Asynchronous Programming, Multi-Agent Systems, Durable Workflows, Task Orchestration, Agentic AI Foundation (AAIF)

Source: https://www.youtube.com/watch?v=dSoXxTqHJv0