Drop the Tasks extension; defer to a SEP-2663 rewrite

The Tasks implementation was built against the 2025-11-25 in-core design still
carried (types-only) in mcp_types, not SEP-2663 (the extension that ships in
2026-07-28). They diverge on nearly every wire-observable detail: SEP-2663 makes
the server the sole decider (ignoring the legacy params.task), uses the
{tasks/get, tasks/update, tasks/cancel} method set (no tasks/list or
tasks/result), returns a CreateTaskResult discriminated by resultType: "task"
(not a CallToolResult with _meta), advertises {} settings, gates on
execution.taskSupport, and renames ttl/pollInterval to ttlMs/pollIntervalMs.

Remove the extension, its tests, and its story rather than ship a spec-violating
example; restore tasks to the deferred manifest list with a SEP-2663 pointer. The
generic Extension API and the Apps reference extension are unaffected and still
at 100% coverage. Tasks returns as a separate PR rewritten to SEP-2663 with the
conformance tasks-* scenarios wired in.

Author: Kludex

docs/migration.md

@@ -419,18 +419,13 @@ construction:
 ```python
 from mcp.server.mcpserver import MCPServer
 from mcp.server.apps import Apps
-from mcp.server.tasks import Tasks
 
-mcp = MCPServer("demo", extensions=[Apps(), Tasks()])
+mcp = MCPServer("demo", extensions=[Apps()])
 ```
 
-Two reference extensions ship in their own modules:
-
-- `mcp.server.apps.Apps` (`io.modelcontextprotocol/ui`) — binds a tool to a
-  `ui://` UI resource via `_meta.ui.resourceUri`; `client_supports_apps(ctx)`
-  gates the SEP-2133 text-only fallback.
-- `mcp.server.tasks.Tasks` (`io.modelcontextprotocol/tasks`) — intercepts
-  task-augmented `tools/call` and serves the `tasks/*` methods.
+The reference extension is `mcp.server.apps.Apps` (`io.modelcontextprotocol/ui`):
+it binds a tool to a `ui://` UI resource via `_meta.ui.resourceUri`, and
+`client_supports_apps(ctx)` gates the SEP-2133 text-only fallback.
 
 Clients advertise extension support with the new `Client(extensions=...)` /
 `ClientSession(extensions=...)` argument, mirrored into `ClientCapabilities.extensions`.

examples/stories/apps/README.md

@@ -37,5 +37,4 @@ uv run python -m stories.apps.client --http
 
 ## See also
 
-`tasks/` (the interceptive half of the extension API),
 `custom_methods/` (registering a non-spec method without an extension).

examples/stories/manifest.toml

@@ -56,13 +56,6 @@ lowlevel   = false
 transports = ["in-memory", "http-asgi"]
 era        = "dual-in-body"
 
-[story.tasks]
-# Interceptive extension; the tasks/* methods drop to client.session like custom_methods.
-# extensions ride server/discover (modern-only), so the connection is pinned to "auto".
-lowlevel   = false
-transports = ["in-memory", "http-asgi"]
-era        = "dual-in-body"
-
 [story.schema_validators]
 
 [story.middleware]
@@ -157,5 +150,6 @@ fixed_port    = 8000                            # issuer/PRM metadata bake in :8
 [deferred]
 caching       = "client honouring + per-result override unlanded"
 subscriptions = "#2901 — Client.listen / ServerEventBus"
+tasks         = "SEP-2663 — tasks extension runtime (server-decided augmentation, CreateTaskResult)"
 skills        = "#2896 — SEP-2640"
 events        = "#2901 + #2896"

examples/stories/tasks/README.md

@@ -1,61 +1,24 @@
 # tasks
 
-Task-augmented tool execution. A client sends `tools/call` with a `task` field;
-the server records the call under a task id and the client polls `tasks/get` /
-`tasks/result`. This is the *interceptive* half of the extension API — the
-`Tasks` extension (`io.modelcontextprotocol/tasks`) wraps `tools/call` rather
-than only adding tools.
-
-## Run it
-
-```bash
-# stdio (default — the client spawns the server as a subprocess)
-uv run python -m stories.tasks.client
-
-# HTTP — the client self-hosts the server on a free port, runs, then tears it down
-uv run python -m stories.tasks.client --http
-```
-
-## What to look at
-
-- `server.py` `MCPServer("tasks-example", extensions=[Tasks()])` — opt in at
-  construction. The extension advertises `io.modelcontextprotocol/tasks` and
-  serves `tasks/get`, `tasks/result`, `tasks/cancel`, and `tasks/list`. The
-  `render_report` tool is the kind of slower, multi-step work a caller would
-  rather run as a task than block on.
-- `mcp.server.tasks.Tasks.intercept_tool_call` — the interceptive seam: a plain
-  call passes through; a call with a `task` field is recorded and returned with
-  the task id in `_meta["io.modelcontextprotocol/related-task"]`.
-- `client.py` `main` — start the call as a task, read its `tasks/get` status,
-  then fetch the payload with `tasks/result`. The `task` field and `tasks/*`
-  methods are outside the spec verbs `Client` exposes, so the thin
-  `_start_task` / `_get_task` / `_task_result` helpers wrap `client.session`.
-
-## Caveats
-
-This is a reference implementation for the extension API, not a production task
-runtime. A plain `tools/call` (no `task` field) is unchanged — only a call the
-client explicitly augments with a `task` field becomes a task. Three deliberate
-simplifications:
-
-- The tool runs to completion inline, so a task is observed as `completed`
-  immediately (no detached/background execution, no TTL eviction).
-- The augmented call returns a normal `CallToolResult` with the task id in
-  `_meta` rather than the spec's `CreateTaskResult` — the `tools/call` result
-  schema admits only `CallToolResult | InputRequiredResult` (see `TODO(L56)` in
-  `mcp.server.runner`), so returning `CreateTaskResult` would require extending
-  the methods-layer validation maps. The lifecycle runs through the dedicated
-  `tasks/*` methods instead.
-- Any tool may be task-augmented on request; per-tool gating on the declared
-  `ToolExecution.task_support` (`forbidden`/`optional`/`required`) is not enforced.
+Task-augmented execution: a requestor augments a `tools/call` with a `task`, the
+receiver returns a `CreateTaskResult` immediately, and the requestor polls
+`tasks/get` and retrieves the deferred result.
+
+**Status: deferred.** Tasks ship in 2026-07-28 as
+[SEP-2663](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/seps/2663-tasks-extension.md),
+an `io.modelcontextprotocol/tasks` extension that is wire-incompatible with the
+2025-11-25 in-core design still carried (types-only) in `mcp_types`. The runtime
+needs to be built to the SEP — server-decided augmentation (ignoring the legacy
+`params.task`), the `{tasks/get, tasks/update, tasks/cancel}` method set, the
+`resultType: "task"` envelope, `execution.taskSupport` gating, and `ttlMs`
+fields — so it lands in a separate PR with the conformance `tasks-*` scenarios
+wired in.
 
 ## Spec
 
-[Tasks — extensions](https://modelcontextprotocol.io/specification/draft/extensions)
+[SEP-2663 — Tasks extension](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/seps/2663-tasks-extension.md)
 · [SEP-2133 — extensions capability](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2133)
 
 ## See also
 
-`apps/` (the additive half of the extension API),
-`custom_methods/` (a non-spec method without an extension),
-`middleware/` (the low-level `tools/call` wrapping the interceptor builds on).
+`apps/` (the additive half of the extension API).