Why MCP Tasks Are Hard to Implement

The Challenge of Long-Running Tasks

Model Context Protocol (MCP) tasks are designed to handle long-running operations that survive infrastructure blips, process crashes, and network disconnections. In a standard request-response model, these interruptions break the interaction. MCP tasks solve this by providing a durable handle that allows clients to resume interaction once the infrastructure recovers. The primary difficulty in adoption stems from the complexity of maintaining this state across distributed systems, particularly when waiting for human-in-the-loop inputs.

Evolution from V1 to V2

The V1 specification introduced significant friction by requiring stateful connections to track task progress. Specifically, the task/list endpoint forced clients to query the server for task status without filtering, which fails at scale. Furthermore, the V1 protocol for handling human input required keeping a long-lived session open, which was brittle and difficult to implement.

The V2 specification addresses these issues by moving to a stateless core and treating tasks as an extension. Key changes include:

• Removal of the task/list endpoint to eliminate stateful polling overhead.
• Transition to a stateless interaction model where clients signal updates to the server rather than maintaining open sessions.
• Standardization of the task life cycle (Working, Input Required, Completed, Cancelled, Failed) to map more cleanly to backend domain state machines.

Scaling and Future Implementation

While V2 improves implementation, scaling to millions of tasks remains a challenge because clients still poll for updates. The author suggests that a future notification-based protocol will be necessary, allowing servers to push updates to clients only when a specific task state changes. Current efforts are focused on integrating these patterns into fast-mcp to lower the barrier for developers building durable agentic workflows.