Skip to content

Implement SEP-2663: Tasks Extension #868

Description

@alexhancock

SEP-2663: Tasks Extension — rust-sdk implementation

Spec PR: modelcontextprotocol/modelcontextprotocol#2663
Track: Extensions · Stage: final · Priority: P0 · Theme: Transport Evolution and Scalability
Needs code changes: Yes (Large)

Summary

SEP-2663 moves the experimental tasks feature out of the core 2025-11-25 spec and into an
official MCP extension. A server may respond to a tools/call with an asynchronous task
handle
instead of a final result; the client then polls for the eventual result. The extension
introduces three methods — tasks/get, tasks/update, tasks/cancel — a polymorphic result
discriminator (resultType: "task"), and a Task shape carrying status, in-progress
server→client requests, and a final result or error. Task creation is server-directed: the client
signals support via per-request capabilities and the server decides per-request whether to
materialize a task.

This removes the version of tasks specified in 2025-11-25 and reshapes it to align with
base-protocol changes expected in this release (SEP-2260, SEP-2322).

Why this needs code changes in rust-sdk

The SDK already ships a substantial tasks implementation built around the older SEP-1319 / SEP-1686
design, which SEP-2663 reshapes and relocates:

  • crates/rmcp/src/model/task.rsTask, TaskStatus (Working/InputRequired/Completed/Failed/Cancelled), ListTasksResult (tasks/list).
  • crates/rmcp/src/model.rs — task-augmented request params: CreateMessageRequestParams.task: Option<JsonObject> and CallToolRequestParam.task: Option<JsonObject> with the TaskAugmentedRequestParamsMeta trait and a with_task(..) builder (all commented SEP-1319).
  • crates/rmcp/src/model/capabilities.rsTasksCapability / TaskRequestsCapability (sampling/elicitation/tools) advertised in core capabilities.
  • crates/rmcp/src/task_manager.rs — runtime: OperationProcessor, OperationDescriptor, OperationMessage, TaskResult, ToolCallTaskResult, with submit_operation / check_timeouts / cancel_all_tasks / list_running.

So this is a reshape + relocate, not a greenfield build. The work is migrating these to the
SEP-2663 extension shape and decoupling tasks from the core capability set.

Proposed work

  • Re-model Task in model/task.rs to the SEP-2663 shape (status, in-progress server→client requests, final result/error, polling interval); reconcile with the existing TaskStatus enum (likely mostly reusable).
  • Replace the _meta.task: Option<JsonObject> augmentation pattern (TaskAugmentedRequestParamsMeta, with_task) with the SEP-2663 per-request capability signaling — server decides per-request whether to materialize a task.
  • Add the resultType: "task" polymorphic discriminator to tools/call (and sampling) result deserialization in model.rs / model/serde_impl.rs, so a result can be either a final result or a task handle.
  • Add tasks/get, tasks/update, tasks/cancel as const_string! methods with request/result types in model/task.rs, plus server handlers (handler/server/) and client helpers (service/client.rs); deprecate/reconcile the existing tasks/list.
  • Move TasksCapability/TaskRequestsCapability out of core ClientCapabilities/ServerCapabilities and express tasks via the existing extensions: Option<ExtensionCapabilities> field (SEP-2133/1724) under a reverse-domain id.
  • Rework task_manager.rs (OperationProcessor et al.) to be extension-scoped and to align with the new lifecycle.
  • Deprecate the old experimental API with #[deprecated]; document the breaking change.
  • Add conformance coverage and an example.

Affected areas

crates/rmcp/src/model/task.rs, crates/rmcp/src/model.rs (task-augmented params, resultType),
model/serde_impl.rs, model/capabilities.rs (move tasks to extensions),
crates/rmcp/src/task_manager.rs, handler/server/, service/server.rs, service/client.rs.

Notes / risks

  • Depends on SEP-2260 (request association) and SEP-2322 (MRTR) landing; sequence after those.
  • Breaking change vs. the current SEP-1319/1686 implementation — the _meta.task augmentation, with_task, and core TasksCapability all change. Coordinate a clear deprecation/migration note (ties into SEP-2596).
  • The extensions/ExtensionCapabilities plumbing already exists, so the SEP-2133 dependency is light here.

Related existing issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High: significant functionality gap or spec violationT-enhancementNew features and enhancementsT-modelModel/data structure changesT-serviceService layer changes

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions