Stable - implements SEP-2663 (Tasks v2), merged into the MCP spec.
Server-side implementation of the v2 Tasks extension. v2 inverts v1's client-driven model: the server decides when to create a task, and clients call tools/call normally with no task hint.
🚀 Skip to the guided walkthrough → - 8-step demokit walkthrough covering the full v2 surface: extension negotiation, polymorphic
tools/call, inlined results, the newtasks/updateMRTR loop, ack-only cancel, and tool-vs-protocol error semantics. Run it withjust serve+just demo.🔁 Migrating from v1? See the v1 → v2 migration guide for the wire-shape diff, server entry points (
tasks.Registerinext/tasks/server.RegisterTasksV1), and the rolling-upgrade recipe.
| Aspect | v1 (SEP-1686, core 2025-11-25) | v2 (SEP-2663, Final ext) |
|---|---|---|
| Capability slot | capabilities.tasks |
capabilities.extensions["io.modelcontextprotocol/tasks"] |
| Client opt-in | (none) | client.WithTasksExtension() required |
| Client task hint | task: {ttl, pollInterval} in params |
none - server decides |
Discriminator on tools/call |
absent (use taskId presence) |
resultType: "task" |
| Read endpoints | tasks/get + tasks/result (two RTTs) |
tasks/get only (result inlined) |
Result on terminal tasks/get |
only status - fetch separately | inlined result / error / inputRequests |
| MRTR resume path | side-channel via tasks/result long-poll |
tasks/update (new method) |
tasks/cancel response |
rich task envelope | empty {} ack |
| TTL field | ttl (ms by convention) |
ttlMs (integer milliseconds) |
| Poll-interval field | pollInterval |
pollIntervalMs (integer milliseconds) |
| Tool errors | status: failed |
status: completed, result.isError: true |
| Protocol errors | status: failed, error: ... |
status: failed, error: {code, message, data} |
tasks/list |
exists | removed |
| Mcp-Name HTTP header | not set | set on task-creating responses (SEP-2243) |
just serve # terminal 1: v2 tasks server on :8080
just demo # terminal 2: demokit walkthrough (7 steps)See WALKTHROUGH.md for the full step-by-step description and sequence diagram.
Moved. An agent driving these task tools is now demonstrated in
chakra, the agent SDK, which was extracted from mcpkit into its
own repository. The point it made still holds and is covered there by host/tasks_test.go and the
agent-async example: a model calls a sync-only tool and a server-directed async tool the same way,
and the SEP-2663 task machinery never surfaces to it.
This example stays focused on the server side.
- Tasks-as-extension negotiation.
client.WithTasksExtension()opts in during initialize; servers gate task-creatingtools/calland everytasks/*method on it. - Polymorphic
tools/callwith theresultType: "task"discriminator, so the server decides whether to create a task, no client hint required. - Inlined results on terminal
tasks/get, whereresult/error/inputRequestsarrive in one RTT,tasks/resultremoved. - Tool-vs-protocol error semantics: tool errors land in
status: completed, isError: true; protocol errors instatus: failedwith structurederror. - Empty-ack
tasks/cancelplus follow-uptasks/getto observe the resultingcancelledstatus. - The new
tasks/updateMRTR resume path closing the elicitation/sampling loop. - The
Mcp-NameHTTP response header (SEP-2243) carrying taskIds for observability without parsing the body. - TaskCallbacks proxy pattern (external task store) via
external_job.
| Tool | TaskSupport | What it demonstrates |
|---|---|---|
greet |
forbidden | Sync-only - server returns ToolResult directly, no resultType |
slow_compute |
optional | Server creates a task; client gets resultType: "task" discriminator |
failing_job |
required | Tool error path → terminal completed + isError: true |
protocol_error_job |
required | Protocol error path → terminal failed + error: {...} |
external_job |
required | TaskCallbacks proxy pattern (external task store) |
- Scenarios live in the
panyam/mcpconformancefork (branchfeat/tasks-mrtr-extension, upstream Draft PR modelcontextprotocol/conformance#262). Run viajust testconf-tasks-v2from the repo root, which points the fork's vitest run at this binary. - Migration guide:
docs/TASKS_V2_MIGRATION.md - Spec: SEP-2663
- v1 example:
examples/tasks/ - Server library:
ext/tasks/tasks.go - Wire types:
core/task_v2.go - Client helpers:
client/tasks.go(ToolCall,GetTask,WaitForTask,UpdateTask,CancelTask) - Conformance scenarios: panyam/mcpconformance,
src/scenarios/server/tasks/ - Local sentinel for mcpkit-stricter scenarios:
conformance/tasks-v2/