|
1 | 1 | # tasks |
2 | 2 |
|
3 | | -Task-augmented execution: a requestor augments a `tools/call` with a `task`, the |
4 | | -receiver returns a `CreateTaskResult` immediately, and the requestor polls |
5 | | -`tasks/get` and retrieves the deferred result. |
6 | | - |
7 | | -**Status: deferred.** Tasks ship in 2026-07-28 as |
8 | | -[SEP-2663](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/seps/2663-tasks-extension.md), |
9 | | -an `io.modelcontextprotocol/tasks` extension that is wire-incompatible with the |
10 | | -2025-11-25 in-core design still carried (types-only) in `mcp_types`. The runtime |
11 | | -needs to be built to the SEP — server-decided augmentation (ignoring the legacy |
12 | | -`params.task`), the `{tasks/get, tasks/update, tasks/cancel}` method set, the |
13 | | -`resultType: "task"` envelope, `execution.taskSupport` gating, and `ttlMs` |
14 | | -fields — so it lands in a separate PR with the conformance `tasks-*` scenarios |
15 | | -wired in. |
| 3 | +Task-augmented execution (SEP-2663). A client declares the |
| 4 | +`io.modelcontextprotocol/tasks` extension; the server may then answer a |
| 5 | +`tools/call` with a `CreateTaskResult` (carrying a task id) instead of blocking, |
| 6 | +and the client polls `tasks/get` for status and the eventual result. |
| 7 | + |
| 8 | +## Run it |
| 9 | + |
| 10 | +```bash |
| 11 | +# stdio (default — the client spawns the server as a subprocess) |
| 12 | +uv run python -m stories.tasks.client |
| 13 | + |
| 14 | +# HTTP — the client self-hosts the server on a free port, runs, then tears it down |
| 15 | +uv run python -m stories.tasks.client --http |
| 16 | +``` |
| 17 | + |
| 18 | +## What to look at |
| 19 | + |
| 20 | +- `server.py` `MCPServer("tasks-example", extensions=[Tasks(default_ttl_ms=...)])` — |
| 21 | + opt in at construction. The extension advertises `io.modelcontextprotocol/tasks` |
| 22 | + and serves `tasks/get` and `tasks/cancel`. |
| 23 | +- `mcp.server.tasks.Tasks.intercept_tool_call` — the server DECIDES augmentation; |
| 24 | + the legacy `params.task` field is ignored. It augments only for a client that |
| 25 | + declared the extension on the request, returning a flat `CreateTaskResult` |
| 26 | + (`resultType: "task"`). |
| 27 | +- `client.py` `Client(target, extensions={EXTENSION_ID: {}})` — declaring the |
| 28 | + extension is what lets the server defer; `main` then reads the `CreateTaskResult` |
| 29 | + and polls `tasks/get`, whose completed `DetailedTask` inlines the original |
| 30 | + `CallToolResult`. |
| 31 | + |
| 32 | +## Scope |
| 33 | + |
| 34 | +This is the SEP-2663 conformant *core*. The tool runs to completion inline (so a |
| 35 | +task is observed as `completed` immediately), and the store is in-memory. Deferred |
| 36 | +to follow-ups, each needing deeper SDK plumbing: `tasks/update` + the MRTR |
| 37 | +`input_required` loop, `ToolExecution.taskSupport` gating with the `-32021` |
| 38 | +required-task error, `notifications/tasks`, and SEP-2243 task routing headers. |
16 | 39 |
|
17 | 40 | ## Spec |
18 | 41 |
|
19 | | -[SEP-2663 — Tasks extension](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/seps/2663-tasks-extension.md) |
| 42 | +[SEP-2663 — Tasks extension](https://modelcontextprotocol.io/seps/2663-tasks-extension.md) |
20 | 43 | · [SEP-2133 — extensions capability](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2133) |
21 | 44 |
|
22 | 45 | ## See also |
23 | 46 |
|
24 | | -`apps/` (the additive half of the extension API). |
| 47 | +`apps/` (the additive half of the extension API), |
| 48 | +`custom_methods/` (a non-spec method without an extension). |
0 commit comments