MCP Tasks Explained: How to Run Longer AI Tasks Reliably

An AI agent needs to analyze 500 documents, review a large codebase, or check several server configurations. But the job takes longer than a regular tool call. What happens if the connection drops, the client stops waiting, or processing takes several minutes?

This is exactly where MCP Tasks come in. The Model Context Protocol (MCP) lets AI applications talk to external tools, data sources, and services. For the basics of MCP itself, see Model Context Protocol (MCP) Explained Simply (Read article). MCP Tasks extend this idea with a standardized way to treat long-running operations as their own tasks.

Instead of waiting for a single, potentially very long response, a client can start a task, poll its status, and retrieve the result later. That's especially interesting for AI agents, automations, and enterprise applications.

Editorial note: This article describes the MCP Tasks extension (SEP-2663) based on the official MCP specification. Because protocol details and SDK support keep evolving, implementations should be verified against the specific MCP version in use before production deployment. State of this article: October 21, 2026.

1. What are MCP Tasks?

MCP Tasks are a mechanism for managing long-running operations within the Model Context Protocol. A task isn't treated purely as an ordinary synchronous request — instead, it gets its own task ID, a traceable processing state, and a defined path to the eventual result.

The basic principle breaks down into four steps:

1. An MCP client signals in its request that it supports the Tasks extension, and starts a task on an MCP server.
2. The server decides whether to respond directly or create a task, acknowledges the request, and returns a task ID.
3. The client can poll the current processing status with tasks/get.
4. Once the task is complete, that same response contains the finished result.

The key benefit: the original request doesn't have to stay open for the entire duration of processing. That doesn't automatically mean every task survives a server restart, though — for that, the MCP server needs a suitable persistent task store.

2. Why ordinary MCP tool calls hit their limits

A classic MCP tool call works great for short operations: reading a config file, querying a database, or checking a single service's status. Things get trickier with time-intensive work — for example, when an AI agent needs to scan 200 log files for errors, audit a large Git repository, classify several thousand documents, or run a full infrastructure inventory.

Processes like that can take minutes or even hours. With a purely synchronous call, several risks show up: network connections can drop, timeouts can prevent the response from arriving, clients can restart, and results can get lost even though the actual processing already finished. MCP Tasks solve this by separating a task's execution from immediately receiving its result.

3. How MCP Tasks work technically

The flow follows a fixed pattern of capability negotiation, task creation, polling, and an optional mid-flight input step:

Flow of an MCP task

Step	Who acts	What happens
1. Capability negotiation	Client	Declares support for io.modelcontextprotocol/tasks in the request metadata
2. Task creation	Server	Returns a CreateTaskResult with resultType: "task", a task ID, status, and TTL instead of the direct result
3. Polling	Client	Repeatedly calls tasks/get until a terminal status is reached
4. Mid-flight input (optional)	Server & client	On input_required, the server returns inputRequests; the client answers via tasks/update
5. Completion	Server	On completed the response carries the result, on failed the error

The task has to be durably created on the server side before the first response carrying the task ID is sent. From then on, the task ID serves as a reference for every further operation, letting processing be tracked independently of when the original response was sent.

Beyond plain polling, servers can also push status changes to clients via notifications/tasks, which clients opt into through the subscriptions/listen mechanism. Where both sides support it, that saves extra tasks/get round-trips, but polling remains the default path whenever a client or server doesn't support notifications.

4. The lifecycle of an MCP task

A task moves through several states. The following statuses matter most for processing:

Status of an MCP task

Task status	Meaning
working	The operation is in progress.
input_required	Continuing requires additional input (see inputRequests).
completed	The operation finished successfully; the result is in the result field.
failed	The operation failed; details are in the error field.
cancelled	The operation was cancelled (not guaranteed in every case).

A task doesn't have to pass through every state — a task that completes successfully can go straight from working to completed, for example. completed, failed, and cancelled are terminal states: once one of them is reached, the task's state no longer changes.

5. MCP Tasks vs. regular MCP tool calls

Comparison: regular tool call vs. MCP task

Property	Regular tool call	MCP task
Execution	Typically synchronous	Asynchronous task model
Task ID	Not required	Present
Poll status separately	Not by default	Yes, via tasks/get
Retrieve result later	Not as its own flow	Yes
Good fit for short actions	Very good	Possible, but usually unnecessary
Good fit for long processes	Limited	Particularly well suited
Cancellation handling	Tied to the call	Tied to the task, via tasks/cancel
Persistence across restarts	Application-specific	Also implementation-dependent

It's important to separate the protocol from the actual execution environment: MCP Tasks provide a standardized task model, but not yet a full job queue, automatic recovery, or a guarantee of exactly-once execution. Developers still need to build those properties themselves.

6. MCP Tasks in practice: a complete walkthrough

The Tasks Extension, identified as io.modelcontextprotocol/tasks, describes a concrete flow for asynchronous tool calls and was adopted as SEP-2663. It differs from the older, experimental tasks functionality in the November 2025 MCP specification, which it has since superseded. The examples below follow the specification revision dated July 28, 2026.

Step 1: Start a task-capable tool call

A client signals in its request that it supports the Tasks extension:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "analyze_logs",
    "arguments": { "source": "server-logs", "hours": 24 },
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": { "io.modelcontextprotocol/tasks": {} }
      }
    }
  }
}

In this example, an MCP server is supposed to analyze the last 24 hours of log files. The server decides whether to answer immediately or create a task — not every tool call has to run asynchronously.

Step 2: The server returns a task ID

If the server opts for task execution, the response might look like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "log-analysis-2026-001",
    "status": "working",
    "createdAt": "2026-10-21T10:00:00Z",
    "lastUpdatedAt": "2026-10-21T10:00:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000
  }
}

Simplified, illustrative example. The task ID and timestamps are fictional; exact field names may vary slightly between SDK versions.

The most important fields: resultType marks the response as a task, taskId is the unique reference, status is the current processing state, ttlMs is the intended lifetime in milliseconds, and pollIntervalMs is the suggested polling interval.

Steps 3 and 4: Poll status and retrieve the result

The client polls the processing state with tasks/get:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/get",
  "params": { "taskId": "log-analysis-2026-001" }
}

The client should respect the server's suggested polling interval. Polling too often adds unnecessary server load and can trigger rate limits. Once the task is complete, the tasks/get response carries status completed and the actual result in the result field — the AI agent can then keep working with that result, for example to produce a report or kick off further analysis.

A note on older MCP tutorials: an earlier method called tasks/result is not part of the current Tasks Extension. The finished result is returned via tasks/get instead.

7. What happens when an MCP task needs extra input?

Not every task can run to completion without further interaction. An AI agent might, for instance, prepare a deployment and then need an approval before continuing. That's what the input_required status is for: the server exposes open input requests via inputRequests, and the client answers them with tasks/update.

A typical flow: a deployment task starts, the server requests approval via input_required, an authorized user makes a decision, the client submits the answer with tasks/update, and the task either continues or ends in a controlled way. This concept is especially valuable for AI agents because it means longer workflows don't have to run fully autonomously — a company might, for example, require that changes to production systems only happen after explicit approval. That said, technical support for an input request is no substitute for real authorization checks.

8. Implementing MCP Tasks reliably: the key architecture rules

An MCP task is only as reliable as the infrastructure it runs on. If you want to use Tasks in production, you shouldn't rely solely on the MCP server process itself.

1. Persist task state. A simple in-memory task store can be enough for early testing. In production, though, a problem shows up: if the MCP server restarts, stored task information can be lost. A more robust architecture might use PostgreSQL for task state and a suitable job queue for execution.

2. Separate workers from the API. The MCP interface doesn't necessarily have to execute every task itself. One possible architecture: the MCP server accepts requests and manages tasks, PostgreSQL stores task status and metadata, Redis or a job queue distributes work to workers, the workers run the time-intensive operations, an object store holds large results, and monitoring watches errors, runtimes, and queue load. This separation makes scaling easier and keeps expensive analysis work from blocking the MCP server itself.

3. Make retries safe. After a network error, it can be unclear whether a request already ran — which is especially dangerous for tasks like creating invoices, modifying user accounts, provisioning infrastructure, or running database migrations. Operations like these should be made idempotent wherever possible, for example with application-specific idempotency keys, unique job references, and transactions.

4. Distinguish timeouts from retention periods. A common architecture mistake is treating every time limit as the same thing. In reality, several values need to be kept separate: the HTTP timeout for a single network operation, the task runtime limit for how long processing may take, pollIntervalMs for the suggested polling frequency, ttlMs for how long the task is meant to stay usable per the protocol metadata, and a separate result-retention period. A long task runtime doesn't automatically mean the results stay available indefinitely.

5. Handle cancellation correctly. A client can try to cancel a running task via tasks/cancel:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tasks/cancel",
  "params": { "taskId": "log-analysis-2026-001" }
}

One detail matters here: the server acknowledges the cancellation request with an empty result, but a successful cancel request doesn't guarantee the underlying processing has already stopped. Cancellation is cooperative — actual termination can be delayed or may not happen at all, and the task can still end up in a terminal state other than cancelled.

9. A practical example: infrastructure checks with an AI agent

Picture a company with several Linux servers, databases, and reverse proxies. An administrator wants to run an automated infrastructure check every morning. The AI agent should check the health of all relevant servers, flag failing services, analyze system logs, spot suspicious configuration changes, and produce a summary report.

For a larger infrastructure, this can take several minutes. With MCP Tasks, the agent can start the check, go do other work in the meantime, and check the status later. The real benefit is that the AI application isn't permanently tied to one open request. That said, after a connection drop, the agent should reuse the existing task ID instead of blindly starting the same operation again.

10. Security: what risks do MCP Tasks introduce?

Longer-running tasks can process sensitive data and trigger actions with far-reaching consequences. That makes security measures especially important.

Secure access to task results. A task ID must not be treated as sole proof of authorization. An MCP server has to check whether the requesting client is actually allowed to access the task and its results — otherwise, users could try to poll other people's task IDs and obtain confidential information. I cover how an MCP server decides who gets access at all in much more detail in MCP Authentication Explained: OAuth, Tokens, and Secure Access (Read article).

Keep permissions tightly scoped. An AI agent that's supposed to analyze log files normally doesn't need administrator rights on every server. The principle of least privilege applies to MCP Tasks as well.

Account for prompt injection. A task can process external documents, web pages, or log files. That kind of data can contain manipulated instructions trying to influence an AI agent's behavior. External content must therefore be treated as untrusted — an analysis task, for example, must not transmit credentials to an external server just because a log file happened to contain an instruction telling it to. I walk through the concrete attack paths and how to defend against them in MCP and Prompt Injection: Why External Data Can Be Dangerous (Read article).

Keep audit logs. For security-critical tasks, you should log at least: who started the task, which tool was called, which permissions were used, when the task started and ended, which approvals were granted, and whether execution succeeded. Make sure logs never capture passwords, API keys, or unnecessary personal data.

11. MCP Tasks, n8n, and classic job queues: what's the difference?

MCP Tasks don't automatically replace existing workflow engines or background-processing systems. They solve different problems.

MCP Tasks compared to other technologies

Technology	Main purpose	Typical use
MCP Tasks	Manage long-running MCP operations	An AI agent starts an analysis through an MCP server
n8n	Orchestrate workflows	Connecting CRM, email, and databases
Celery	Run background jobs	Distributing Python tasks
Redis Queue	Distribute and process jobs	Background processing
Kubernetes Jobs	Containerized batch work	Scalable infrastructure jobs

These technologies can be combined: an MCP server could create a task, push a background job onto a queue, and surface the result back through the MCP interface once it's done. n8n could handle notifying an administrator or forwarding a report in parallel — I describe how to expose n8n itself as an MCP server for AI agents in n8n as an MCP Server: Exposing Workflows to AI Agents (Read article). That doesn't mean every n8n installation or every MCP server automatically supports the Tasks Extension, though — it still has to be explicitly implemented or supported by the product in question.

12. MCP Tasks and Kubernetes: a sensible combination?

MCP Tasks get especially interesting in containerized environments. An MCP server can run in Kubernetes while workers handle time-intensive work, and separate Kubernetes Jobs can take on large analysis workloads. A few technical details matter here:

• Persistence: Task state must not live purely in a single pod's memory.
• Scaling: Multiple MCP server instances need access to consistent task information.
• Routing: MCP's Streamable HTTP transport uses the Mcp-Session-Id header for session routing. The task ID itself isn't carried in its own HTTP header — it travels in the JSON-RPC request body. Behind a load balancer with multiple MCP server instances, routing still has to make sure requests for the same session are handled consistently so that running tasks stay reachable.
• Error handling: If a worker is terminated, the application has to decide whether to retry, resume, or mark the task failed.
• Monitoring: Metrics like task runtime, error rate, and queue wait time help catch problems early.

The MCP specification defines the communication interface. The actual execution strategy remains up to the infrastructure.

13. Mistakes to avoid with MCP Tasks

Common mistakes and better approaches

Mistake	Better approach
Keeping the task ID only in the client's memory	Persist the task ID
Polling status every second	Respect pollIntervalMs or use notifications
Starting a new task on every network error	Check for an existing task first
Running tasks with no runtime limit	Set appropriate limits
Storing results indefinitely	Define retention rules
Treating the task ID as an access credential	Verify authentication and authorization
Treating cancellation as immediate termination	Account for cooperative cancellation
Mixing MCP Tasks versions	Check the extension and protocol version

That last point matters in particular: older examples from MCP's development can use different methods, fields, and capability declarations. Copying them unchanged risks incompatibilities.

14. When are MCP Tasks actually worth it?

Not every AI action needs its own task. A simple database query that finishes in a few milliseconds can still run synchronously without any issue. MCP Tasks are worth considering when at least one of the following applies: processing takes noticeably longer than a regular tool call; results need to stay retrievable after a connection drop; a client needs to track processing status; a task needs additional input partway through; or processing should be independent of a single client connection.

Whether MCP Tasks are the right fit also depends on support from the specific MCP client and server in use — not every product has fully implemented the extension yet.

Conclusion: MCP Tasks make longer AI processes more manageable

MCP Tasks are an important building block for AI agents that need to do more than short tool calls. They make it possible to start longer-running work, poll its state, handle additional input, and pick up the result later. That makes it possible to build more complex AI workflows without tying every operation to one permanently open client request.

For production use, though, it's crucial to remember that MCP Tasks don't automatically replace a reliable execution infrastructure. Persistence, permissions, monitoring, retry strategies, and error handling still need careful planning. Get those right, and MCP Tasks become a solid foundation for robust AI automation — from log analysis to document processing to large-scale infrastructure checks.

The key takeaway: an AI agent doesn't have to finish every task immediately. What matters is that it can track the task's state and reliably keep working once the result arrives.

FAQ: MCP Tasks

Are MCP Tasks part of MCP?

MCP Tasks are an optional extension to the core MCP protocol (SEP-2663, the Tasks Extension), which has now reached Final status. Clients and servers each have to explicitly enable the extension through capability negotiation. Not every MCP client or server supports it automatically.

Can MCP Tasks run for several hours?

In principle, yes, as long as the server, workers, runtime limits, and retention rules are designed for it. The protocol extension itself does not guarantee any specific maximum execution time.

What happens if the MCP client crashes?

If the client has durably stored the task ID and the server still holds the task, the client can later poll the status again with tasks/get. Whether this resumption works depends on the implementation and the task's TTL.

Can MCP Tasks be retried automatically?

Automatic retries of failed work are not a general guarantee of the Tasks Extension. Retry rules, idempotency, and recovery mechanisms have to be implemented at the application level.

Can MCP Tasks be cancelled?

Yes. A client can request cancellation via tasks/cancel. The actual termination is cooperative: the server acknowledges the request but is not obligated to stop processing immediately.

Are MCP Tasks the same as ChatGPT Scheduled Tasks?

No. ChatGPT Scheduled Tasks are for running tasks within ChatGPT on a schedule or recurring basis. MCP Tasks, by contrast, describe a protocol mechanism for managing asynchronous operations between MCP clients and MCP servers.

Do I need Redis or PostgreSQL for MCP Tasks?

Not necessarily. Other storage options can be enough for simple tests. For production systems with multiple server instances, longer runtimes, and high reliability requirements, persistent, coordinated storage is usually worthwhile, though.

Sources and currency

This article reflects the state of the official MCP specification as of October 2026. Technical details were checked against the official MCP Tasks documentation and the SEP-2663 Tasks Extension specification. The full technical specification lives in the Model Context Protocol ext-tasks repository.

Related topics

Model Context Protocol (MCP) Explained Simply (Read article)

Build Your Own MCP Server: Architecture and a Practical Example (Read article)

MCP Authentication Explained: OAuth, Tokens, and Secure Access (Read article)

MCP and Prompt Injection: Why External Data Can Be Dangerous (Read article)

n8n as an MCP Server: Exposing Workflows to AI Agents (Read article)

AI Skills, Plugins, Apps, and MCP: What's Actually the Difference? (Read article)

Updated: October 2026.