[MCP] Port run_agent tasks from 2025-11-25 experimental API to SEP-2663 / 2026-07-28 ext-tasks #115

Motivation

#102 / draft PR #106 correctly land run_agent as an MCP task on the 2025-11-25 experimental shape that mcp 1.30 still ships (capabilities.tasks, params.task, tasks/get|result|list|cancel). The PR body already records the spike finding: that experimental API is deprecated, and a host that speaks only the official Tasks extension keeps the plain synchronous call.

That official extension is now published:

• Spec: Tasks extension (io.modelcontextprotocol/tasks), revision 2026-07-28
• SEP: SEP-2663 (Final; moves tasks out of core into an extension)
• Overview + reference: modelcontextprotocol.io/extensions/tasks, modelcontextprotocol/ext-tasks

Wire differences that matter for s1a-mcp (non-exhaustive; follow the spec):

• Capability is per-request extensions["io.modelcontextprotocol/tasks"], not the old capabilities.tasks blob.
• Server returns resultType: "task" / CreateTaskResult; clients poll tasks/get (and optionally tasks/update / tasks/cancel).
• Status set is working | input_required | completed | failed | cancelled; tool-level isError: true stays completed with the tool result (protocol faults use failed).
• Hosts that only negotiate the extension will never send the 2025-11-25 params.task flag that [Feat] Let run_agent run as an MCP task (2025-11-25 experimental tasks on the 1.x SDK) #106 keys off.

Until this port lands, Claude Code / other 2026-07-28 hosts that advertise the extension still cannot get a durable handle for a multi-minute Allrecipes / Flights run_agent.

Proposed work

1. After [MCP] Adopt MCP Tasks so long run_agent can outlive the host session #102 / [Feat] Let run_agent run as an MCP task (2025-11-25 experimental tasks on the 1.x SDK) #106 merge (or in parallel behind a feature flag): spike which mcp / FastMCP release first speaks io.modelcontextprotocol/tasks. Record whether the mcp 2 / fastmcp 4 move from #74 is now a hard prerequisite.
2. Advertise the extension in server discover capabilities; treat a client that only sends the extension (no experimental task param) as task-capable for run_agent.
3. Map the existing in-memory task store + cancel/CancelScope path from [Feat] Let run_agent run as an MCP task (2025-11-25 experimental tasks on the 1.x SDK) #106 onto the extension methods; keep the experimental path working until hosts drop it, or document a cutover window.
4. Contract tests with a fake client capability blob for: extension-only client, experimental-only client, neither (sync path). No live browser required.
5. Update docs/skills.md / docs/architecture.md: which host protocol revision was verified; do not invent host flags.

Acceptance criteria

• Client without any tasks capability: behaviour matches today's sync path (existing MCP tests pass).
• Client advertising only io.modelcontextprotocol/tasks: run_agent returns a task handle; tasks/get reaches a terminal status with the same summary shape as the sync tool result; tasks/cancel frees the run slot.
• Experimental 2025-11-25 path either still works or is explicitly removed with a CHANGELOG note and a migration sentence in the docs.
• Docs name the SDK / FastMCP versions that were tested; no unverified host CLI flags.

References

• https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks
• https://modelcontextprotocol.io/seps/2663-tasks-extension
• https://modelcontextprotocol.io/extensions/tasks/overview
• https://github.com/modelcontextprotocol/ext-tasks
• Related: [MCP] Adopt MCP Tasks so long run_agent can outlive the host session #102, [Feat] Let run_agent run as an MCP task (2025-11-25 experimental tasks on the 1.x SDK) #106, [Deps] Bound mcp below 2 and record what blocks the move to the 2026-07-28 SDK #74, [MCP] Keep long run_agent calls inside host tool timeouts: progress, bounded lock wait, cancellation, documented settings #83