Implement SEP-2663: Tasks Extension

[felixweinberger]

This is a tracking issue for implementation of SEP-2663.

[mattzcarey]

Status — SEP-2663 (Tasks Extension)

Track: B — last in the dependency chain: needs #2188 (Extensions framework) and #2187 (MRTR) before this can really land.
Spec: seps/2663-tasks-extension.md · merged spec#2663 2026-05-15

What's done

• main still carries the 2025-11 experimental tasks machinery (_taskManager, ExperimentalServerTasks, ExperimentalClientTasks, BaseContext.task, RequestOptions.task, processInbound*/processOutbound* interception). This is on its way out.
• Closed exploration:
  • refactor(core)!: remove experimental tasks interception from Protocol (R0) #2004 (closed) — first attempt to remove experimental tasks interception from Protocol
  • refactor(core)!: remove experimental tasks interception from Protocol #2055 (closed) — second attempt; keeps storage interfaces (InMemoryTaskStore etc.)
  • feat(core,server,client)!: tasksPlugin() replaces 2025-11 interception; remove Experimental*Tasks classes (SEP-2663) #2066 (closed) — tasksPlugin({store}) as DispatchMiddleware registered via mcp.use(...); handles tasks/get|list|cancel|result; injects ctx.ext.task; taskContext(ctx) helper. Marks ExperimentalServerTasks.getTask/listTasks as @deprecated throw-stubs.

Open PR

• [SEP-2663] refactor!: remove 2025-11 experimental tasks #2128 — [SEP-2663] refactor!: remove 2025-11 experimental tasks (the v2-stateless stack base). Mechanical deletion (+272/-17461). Ships first so the rest of the stack doesn't have to preserve the old interception.

Outstanding (acceptance criteria, summary)

• New extension id io.modelcontextprotocol/tasks; capability negotiation via Implement SEP-2133: Extensions framework for MCP #2188
• resultType: "task" on CreateTaskResult; server MUST NOT return it without the capability
• Methods: tasks/get, tasks/update, tasks/cancel (poll-based; tasks/result removed → -32601; tasks/list removed)
• Per-status response shapes: working / input_required / completed / cancelled / failed field requirements
• Durable creation: tasks/get(id) resolves immediately after CreateTaskResult returned
• notifications/cancelled MUST NOT cancel tasks; only tasks/cancel does (eventually-consistent, cooperative)
• Tool-result isError: true → status completed (not failed); failed is for JSON-RPC errors
• Legacy task param on CallToolRequest → silently ignored (not treated as opt-in)
• tasks/get with invalid/unknown taskId → -32602
• subscriptions/listen with taskIds filter without ext-tasks → -32003 with requiredCapabilities
• Mcp-Name: <taskId> header on tasks/get/update/cancel over HTTP (overlap with SEP-2243 Implement SEP-2243: HTTP Standardization #2190)
• Auth-binding evaluated per task request
• Task IDs: 128-bit entropy / UUIDv4 default TaskStore
• Client SHOULD deduplicate inputRequests keys across consecutive polls
• Progress / log messages NOT delivered via subscriptions/listen for tasks

Post-85ec3771 clarifications to fold in

• spec#2756 (open) — specify -32003 error for missing client capability

Related spec / open PRs to monitor

• spec#2694 — Resumable Task Event Streams (post-release-1)
• spec#2679 — Task streaming partial results (post-release-1)
• spec#2669 — Task Interaction Methods (steer/pause/resume) (post-release-1)

Coordination

• Per the track plan: this is Track B's last item, picked up after MRTR (Implement SEP-2322: Multi Round-Trip Requests #2187) and Extensions (Implement SEP-2133: Extensions framework for MCP #2188) land.
• The plugin shape (tasksPlugin via mcp.use(...) from feat(core,server,client)!: tasksPlugin() replaces 2025-11 interception; remove Experimental*Tasks classes (SEP-2663) #2066) is also the reference for how every other future extension will look — worth aligning on naming/API before merging.

[norika1207-lab]

This looks worth pinning down as a protocol-level regression rather than only an implementation bug.

For Tasks Extension, the acceptance test I would want is a minimal client/server fixture that records the exact JSON-RPC or HTTP exchange, then asserts both the wire result and the local lifecycle state after the failure path. In MCP deployments, the dangerous failures are often not just wrong return values; they are pending requests, dropped notifications, mismatched session state, or errors that get translated into a generic response and become impossible to diagnose.

A useful fix boundary would preserve three signals: the protocol error sent to the peer, the local exception or cancellation reason available to application code, and a trace/log field that ties the two together. That makes the behavior debuggable for agent hosts without requiring every host to special-case this SDK detail.