The MCP Tasks Extension: How Long-Running Tool Calls Work in 2026

The MCP 2026-07-28 Release Candidate ships a Tasks extension that solves one of the protocol's most persistent deployment problems: what happens when a tool call takes longer than an HTTP timeout. Here's how Tasks works, what it requires, and when to use it.

The problem Tasks solves

Standard MCP tool calls are synchronous at the HTTP level. The client sends a tools/call request, the server executes the tool, and the response comes back in the same HTTP response. This works fine for fast operations — querying a database, looking up a cached result, calling a fast external API.

It breaks down for operations that take more than a few seconds. Crawling a large site, processing a video, running a code analysis job, waiting on a third-party API with a slow SLA — any of these can exceed serverless function timeouts (typically 60 seconds on Vercel, 30 seconds on Cloudflare Workers). The only options before Tasks were: increase the timeout, break the job into smaller pieces, or build a custom polling mechanism outside the MCP protocol.

Tasks standardizes the polling approach. The server returns immediately with a task ID, and the client polls for completion using the task ID. The server handles the work in the background.

How Tasks works

When a tool supports the Tasks extension, calling it returns a task object instead of an immediate result:

// Standard synchronous tool response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{ "type": "text", "text": "Done." }]
  }
}

// Tasks extension response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "taskId": "task_abc123",
    "status": "pending",
    "estimatedDurationMs": 30000
  }
}

The client then polls the task status endpoint:

// Poll: tasks/get
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/get",
  "params": { "taskId": "task_abc123" }
}

// Response while running
{
  "result": {
    "taskId": "task_abc123",
    "status": "running",
    "progress": 0.4,
    "progressMessage": "Crawling page 40 of 100"
  }
}

// Response when done
{
  "result": {
    "taskId": "task_abc123",
    "status": "completed",
    "output": {
      "content": [{ "type": "text", "text": "Indexed 100 pages." }]
    }
  }
}

There's also a tasks/cancel method for clients that want to abort a running task, and an optional webhook mechanism where the server pushes completion to a client-provided URL instead of waiting for polling.

What Tasks requires on the server side

Tasks is the MCP extension with the highest infrastructure cost, which is why it's an extension rather than a core requirement.

A Tasks-capable MCP server needs three things the base protocol doesn't:

Persistent task storage. Task IDs and their status need to survive across requests. A serverless function that handles the tools/call request can't share state with the function that handles tasks/get unless you write task state to an external store (database, Redis, Supabase, etc.).

Background job execution. The actual work needs to run somewhere that isn't the HTTP request handler. This means a queue (SQS, BullMQ, Inngest, Trigger.dev) or a long-running background worker that processes jobs independently of the request lifecycle.

A runtime with no hard timeout. The background worker needs to be able to run for as long as the job takes — which rules out serverless functions with short timeouts. Options include dedicated servers, container-based workers, or serverless platforms with configurable long timeouts.

For teams already on this kind of infrastructure, Tasks is straightforward to implement. For teams on simple serverless deployments, it's a meaningful architectural change.

When to use Tasks vs. synchronous calls

The rule is simple: use Tasks when the operation can exceed your platform's function timeout, or when the user experience is better with progress updates than with waiting for a single response.

Good candidates for Tasks:

• Site indexing or crawling (seconds to minutes depending on site size)
• Document processing — OCR, transcription, embedding generation for large files
• Code analysis jobs — static analysis, dependency scanning, test runs
• External API calls with unpredictable latency (third-party enrichment, slow LLM pipelines)
• Export or report generation

Operations that should stay synchronous:

• Database reads and cached lookups (milliseconds)
• Vector search and RAG retrieval (sub-second)
• Simple calculations or transformations
• Any operation that reliably completes in under 5 seconds

Tasks and MCP clients

Client support for Tasks varies as of the RC. Claude Desktop and the Anthropic API handle Tasks-aware responses and poll correctly. Cursor and Windsurf have Tasks support in preview. Clients that don't support Tasks will receive the task object and not know what to do with it — they may surface the raw JSON to the user or silently fail.

If you implement Tasks on your server, check whether your target clients support the extension before relying on it. The safe pattern is to make Tasks opt-in at the tool level, with a synchronous fallback for clients that don't declare Tasks capability during server/discover.

How AgentReady handles long-running indexing

AgentReady's submit_site tool currently runs synchronously within Vercel's function timeout. For most documentation sites, crawling and indexing completes within the limit. For very large sites, the tool returns a partial result with the pages it managed to index before the timeout.

Moving submit_site to Tasks is on the roadmap — it would enable full indexing of large sites with progress updates and eliminate the timeout-based truncation. That requires moving the crawl pipeline to a queue-backed architecture, which is planned as part of the control plane work.

In the meantime, refresh_site and ask_site are fast enough to stay synchronous — retrieval and re-indexing from cache complete well within timeout limits.