Issue #263 opened: V3: Tasks extension for long-running deployments

Why

Deploys are the natural async operation here: deploy wait: true currently holds the tool call open polling (#238/#246), bounded by timeout_seconds. The Tasks extension shipping with spec 2026-07-28 models this properly: start a deploy → get a task handle → client polls tasks/get (or the model does other work meanwhile) → collect the result.

⚠️ Do NOT build on the current spec's tasks

The experimental tasks API in spec 2025-11-25 is incompatible with the redesigned stateless Tasks extension in 2026-07-28. Anything built on the experimental API is throwaway. Wait for:

1. Spec 2026-07-28 final (28 July 2026)
2. SDK v2 stable with the tasks extension package
3. At least one mainstream client actually driving tasks/* (support is ~zero today — this is the long pole)

What (when unblocked)

1. deploy gains task-mode: when the client negotiates the tasks extension, return a task handle instead of blocking; keep wait: true polling as fallback forever (Coolify's API is poll-based underneath either way).
2. Candidates beyond deploy: scheduled_tasks run_once (polls up to 90s today), database_backups execution watching, validate_server.
3. Task state maps from Coolify deployment status (queued/in_progress → running, finished → completed, failed/cancelled → failed) + bounded log tail on failure, reusing the #246 machinery.

Sequencing

Blocked on #259 (SDK v2 migration). Revisit ~Sept 2026; check the client support matrix first: https://modelcontextprotocol.io/extensions/client-matrix

Refs: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

🤖 Generated with Claude Code