MCP Tasks vs UHP: durable asynchronous execution

The shortest accurate answer

MCP Tasks makes a long-running MCP operation durable and pollable. UHP standardizes execution through a selected complete agent harness, including the broader response/session/file/artifact lifecycle around that harness.

The overlap is real: both systems expose durable execution state instead of requiring one blocking request. The ownership boundary is different.

Product / application
        │
        │ UHP: execute through a complete harness
        ▼
Agent harness
        │
        │ MCP tools/call
        ▼
MCP server
        │
        │ MCP Tasks: durable async operation
        ▼
Long-running tool / workflow / external job

A UHP-driven harness can call an MCP server that returns an MCP task. That composition does not turn the MCP task into a UHP Response, and it does not establish native UHP adoption by the MCP client or server.

Current maturity

The official modelcontextprotocol/ext-tasks repository identifies MCP Tasks as the official Tasks extension, with extension identifier io.modelcontextprotocol/tasks. It publishes an immutable 2026-07-28 Stable schema snapshot plus a separate development draft schema.

The extension is based on SEP-2663. That proposal was merged on 15 May 2026 and is labelled Final in the MCP specification repository. The redesign moved Tasks out of the older experimental 2025-11-25 core feature and into MCP’s extension mechanism so the lifecycle can evolve independently before any future promotion into core MCP.

The current official Agents Working Group treats Tasks as the foundation for durable asynchronous execution and lists stabilization/core promotion as active work. That roadmap does not make Tasks part of the core 2026-07-28 protocol: today it remains a released official extension.

What MCP Tasks standardizes

MCP Tasks lets a server return a durable task handle instead of keeping a long-running tools/call blocked until completion.

The stable lifecycle is:

1. Capability negotiation — the client declares io.modelcontextprotocol/tasks in its request capabilities; a server that requires the extension can return JSON-RPC error -32003 (Missing Required Client Capability) when it is absent.
2. Task creation — the server may answer a supported operation with CreateTaskResult, resultType: "task", a server-generated taskId, initial status, TTL and polling guidance. The official architecture requires the task to be durably findable before that handle is returned.
3. Polling — the client uses tasks/get and respects pollIntervalMs until the task reaches a terminal state.
4. Mid-flight input — an input_required task exposes named inputRequests; the client answers them through tasks/update, after which execution can continue.
5. Cancellation — tasks/cancel communicates cancellation intent. Cancellation is cooperative, so an acknowledged request does not guarantee the final state will become cancelled.
6. Completion — a terminal task carries either the original operation’s result or a JSON-RPC error. Optional notifications/tasks updates can also flow through MCP’s subscription mechanism.

At the stable 2026-07-28 extension snapshot, task-augmented execution is documented for tools/call.

State model

MCP Tasks status	Meaning
working	The operation is still running.
input_required	The server needs client input before work can continue.
completed	Execution finished successfully and the task carries the final result.
failed	Execution ended with a JSON-RPC error.
cancelled	Execution ended in the cancelled state.

completed, failed, and cancelled are terminal. A task can also carry statusMessage, createdAt, lastUpdatedAt, ttlMs, and pollIntervalMs.

This is deliberately a poll-handle lifecycle, not a general conversation/session object. The extension does not define tasks/list, and its official security guidance treats non-enumerability and high-entropy task IDs as important protections for stored task state.

Security boundary

Three details matter when placing MCP Tasks in an agent architecture:

• Task IDs must resist enumeration. The official guidance says IDs need sufficient entropy and may function as bearer handles for stored state.
• There is no tasks/list. SEP-2663 explicitly removed task enumeration because many MCP deployments cannot safely derive a common authorization scope across unrelated handles.
• Mid-flight input is still a trust boundary. inputRequests can carry elicitation or sampling payloads from server to client, so hosts apply the same trust model they use for those MCP request types.

Those properties help make long-running operations reconnect-safe, but they do not create a portable agent identity, a UHP principal model, or a complete harness security boundary. Existing transport/authentication and host policy still matter.

MCP Tasks vs UHP

Dimension	MCP Tasks	UHP 2026-08-11
Primary boundary	MCP client ↔ MCP server operation	Product/client ↔ UHP server ↔ selected complete harness
Stable identifier	io.modelcontextprotocol/tasks extension, schema 2026-07-28	Protocol version 2026-08-11
Creation model	Server may materialize a durable task for a supported MCP request	Client creates a UHP Response against a configured harness
Current operation coverage	Stable documentation names tools/call	Complete harness task execution surface
Durable handle	taskId	UHP response/session identifiers
Progress retrieval	tasks/get polling; optional task notifications	UHP response lifecycle plus SSE event streaming and retrieval semantics
Mid-flight interaction	input_required + inputRequests + tasks/update	Harness interaction is represented through the UHP response/event/session contract and harness-specific execution behavior
Cancellation	Cooperative tasks/cancel	UHP defines response/session cancellation semantics within its execution contract
Enumeration	No tasks/list	UHP separately defines discovery and scoped object APIs; this is not the MCP Tasks security model
Harness selection/configuration	Not defined by Tasks	Core UHP concern
Sessions/files/artifacts/containers	Not defined by Tasks as a unified harness contract	Part of the broader UHP execution/object model

The useful conclusion is not “MCP Tasks and UHP are the same.” MCP Tasks solves a narrower asynchronous-operation problem inside MCP. UHP solves the complete-harness execution interoperability problem at a higher boundary.

Where the two can compose

A realistic combined deployment can look like this:

1. A product creates a UHP response against a configured harness.
2. The harness decides to call an MCP server through tools/call.
3. That MCP server returns an MCP Tasks handle because the operation is long-running.
4. The harness/MCP client polls tasks/get, supplies any required input, and eventually obtains the MCP operation result.
5. The harness continues its own work and UHP continues to own the product-facing response/session/event lifecycle.

The MCP task can therefore be nested execution state inside a UHP-driven harness run. The two identifiers and state machines remain different objects with different owners.

What not to infer

Caution

• MCP Tasks being a stable official extension does not make it part of core MCP 2026-07-28.
• The stable Tasks extension is not the same wire contract as the older experimental Tasks feature from MCP 2025-11-25; SEP-2663 redesigned and moved that feature into the extensions framework.
• A durable MCP taskId is not a UHP Response or Session identifier.
• input_required in MCP Tasks does not imply that MCP has adopted UHP’s complete harness lifecycle.
• The absence of tasks/list is a deliberate security/scoping choice, not evidence that task state is public or unauthenticated.
• No primary source reviewed establishes a standardized UHP ↔ MCP Tasks binding or native UHP adoption by the MCP project.

Related pages

Read UHP vs MCP for the broader protocol boundary, UHP lifecycle for UHP response/session behavior, UHP security for UHP trust-boundary rules, and Skills Over MCP for a separate MCP extension-track surface.

Primary sources

• Official MCP Tasks extension repository
• MCP Tasks overview and stable lifecycle
• MCP Tasks stable 2026-07-28 schema
• SEP-2663 — Tasks Extension
• MCP Agents Working Group
• UHP 2026-08-11 architecture
• UHP 2026-08-11 lifecycle
• UHP 2026-08-11 tasks