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

Bắt đầu với API ClientExtension.claims() hiện có và tài liệu về Request.name_param, sau đó xem xét vị trí mcp/client/extensions/tasks.py được đề xuất và các bài kiểm thử liên quan. Triển khai hỗ trợ phía client cho kết quả task từ tools/call, polling tasks/get với khả năng hủy thông qua tasks/cancel, và các header định tuyến task; xác nhận hành vi dựa trên các trạng thái task được mô tả và một server tuân thủ đặc tả.

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.