MCP Tasks: durable operations and the UHP boundary

Recover an operation without duplicating its effect

A durable handle solves recovery after the handle is known. It does not by itself solve a connection loss before the client receives that handle. The official Tasks overview still publishes the stable 2026-07-28 extension; the outer execution contract is UHP 2026-09-28 Draft. These are independent coordinates, reviewed 4 October 2026.

Failure point	Information to retain	Safe next action
Handle received, connection then lost	Server identity, authorization context, taskId, original operation	Reconnect to that server and inspect the same task
Request sent, no handle received	Operation identity and any server-specific duplicate-prevention contract	Establish whether work was admitted before retrying a consequential operation
input_required observed	Task handle and named input requests	Answer that task’s request; do not create another task to deliver the input
Terminal result retrieved	Terminal status and operation-specific result/error	Stop polling; persist the result before discarding the handle

For example, a report-generation tool inside a harness may outlive a lost SSE connection. Preserve the MCP task handle alongside the UHP Response and Session identities, then reconcile each lifecycle separately. A resumed outer Response does not prove the inner report has completed. If the tool sends payments or writes files, resubmitting it can repeat an external effect even when the first client saw no result. This is an implementation recovery rule, not a universal idempotency guarantee added by the extension.

Build around the durable handle

The current official Tasks overview, reviewed 4 October 2026, describes io.modelcontextprotocol/tasks as an extension. Its stable schema is versioned separately from implementation libraries. Support must be advertised by the server and included in the client’s per-request capabilities.

A client workflow

Supported operation, with task capability
  → server durably stores work and returns task handle
  → tasks/get, respecting pollIntervalMs
  → input_required? collect authorized input, then tasks/update
  → completed / failed / cancelled

This is a conceptual sequence; it omits required request metadata and is not a copy-paste wire payload. The final result or error is returned with terminal state. Do not poll as fast as possible or treat successful handle creation as task completion.

Observation	Client response
Connection lost after creation	Retain the handle and reconnect to inspect it
input_required	Apply the normal elicitation/sampling trust policy before responding
TTL expires or handle is unavailable	Report lost/unavailable state; do not invent a successful result
Cancellation requested	Observe the terminal outcome; a request is not proof of rollback
completed	Consume the original operation’s result, not a UHP Response by assumption

Keep task handles out of public logs and cross-tenant views; they identify stored work and the extension’s security model matters independently of transport. The current design does not provide general task enumeration.

Compose with a harness deliberately

A UHP-driven harness may call an MCP server whose operation becomes an MCP task. Your implementation must decide whether the outer run waits, persists the inner handle, requests user input or reports a recoverable failure. There is no automatic identity or cancellation mapping. Use UHP lifecycle and UHP vs MCP alongside the extension.

The earlier stable-schema analysis remains below. Its UHP 2026-08-11 comparison is historical; current UHP is 2026-09-28 Draft.

Historical source notes — baseline reviewed 6 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

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