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

Comienza con la API existente ClientExtension.claims() y la documentación de Request.name_param; después, revisa la ubicación propuesta mcp/client/extensions/tasks.py y las pruebas relacionadas. Implementa la compatibilidad del cliente con los resultados de tareas de tools/call, el sondeo de tasks/get con cancelación mediante tasks/cancel y los encabezados de enrutamiento de tareas; confirma el comportamiento según los estados de tarea descritos y un servidor conforme con la especificación.

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.