modelcontextprotocol / modelcontextprotocol/python-sdk

Client-side support for the tasks extension (io.modelcontextprotocol/tasks, SEP-2663)

Open
#3,226 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P2 spec-2026-07-28 v2
Dominant language
Python
Stars
24.3k
Forks
4k
Avg merge
1d 1h
Merged PRs (30d)
31

Description

v2 removed the experimental tasks API in favor of the SEP-2663 extension (io.modelcontextprotocol/tasks), but the SDK currently ships no client-side way to consume task-augmented servers: a tools/call that returns resultType: "task" fails result validation unless every consumer hand-writes a ResultClaim.

The extension surface (ClientExtension.claims()) supports this cleanly. I have a working implementation (~120 lines + tests, exercised against a spec-conformant 2026-07-28 server with server-directed task creation) that:

  • advertises io.modelcontextprotocol/tasks in per-request capabilities,
  • claims resultType: "task" on tools/call,
  • resolves the claim by polling tasks/get (honoring pollIntervalMs, including mid-task changes),
  • maps failed → a raised error carrying the server's JSON-RPC error, and cancelled → a distinct error,
  • sends best-effort tasks/cancel when the caller's scope is cancelled (shielded), per the spec's cooperative-cancellation model,
  • sets Mcp-Name to the taskId on tasks/* requests via name_param (the SEP-2663 routing-header requirement — the Request.name_param docstring in mcp-types already anticipates this).

Happy to send a PR — proposed location mcp/client/extensions/tasks.py. Two design questions I'd like a maintainer opinion on before polishing:

  1. Should input_required tasks surface through the existing elicitation callback plumbing (with tasks/update as the response channel), or is that a follow-up?
  2. Is transparent-polling-inside-call_tool the right default, or should the extension also expose the raw task handle for callers that want to manage polling themselves (e.g. UI progress)?

One porting note: the natural base for the wire models is MCPModel (camelCase alias generator), which mcp_types doesn't currently re-export — part of the value of upstreaming is resolving that properly.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing ClientExtension.claims() API and Request.name_param documentation, then review the proposed mcp/client/extensions/tasks.py location and related tests. Implement client support for task results from tools/call, polling tasks/get with cancellation through tasks/cancel, and task routing headers; confirm behavior against the described task states and spec-conformant server.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend-api-design
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.