Adopt the io.modelcontextprotocol/tasks MCP extension for long-running server operations

Documented steps

1. Read https://modelcontextprotocol.io/extensions/tasks/overview and https://modelcontextprotocol.io/extensions/overview. Tasks moved out of the core protocol into an official extension in the 2026-07-28 revision (SEP-2663).
2. Use the exact extension identifier 'io.modelcontextprotocol/tasks'.
3. Client: opt in per request via _meta['io.modelcontextprotocol/clientCapabilities'].extensions, e.g. {'extensions': {'io.modelcontextprotocol/tasks': {}}}. Extensions are always disabled by default and require explicit opt-in.
4. Server: advertise the same identifier under capabilities.extensions in your server/discover result.
5. Server: to hand back a task, return a CreateTaskResult identified by resultType 'task', containing taskId, the initial status, ttlMs and pollIntervalMs. Create the task durably BEFORE sending that response.
6. Server: never return a task to a client that did not declare support for the extension.
7. Client: persist taskId durably — the protocol is stateless and a dropped connection does not cancel the work.
8. Client: poll with 'tasks/get', respecting the server's pollIntervalMs.
9. Handle the five task status values: 'working' (in progress), 'input_required' (server needs client input, see inputRequests), 'completed' (result field holds the output), 'failed' (error field holds a JSON-RPC error), 'cancelled'. The last three are terminal and never change once reached.
10. On 'input_required', submit inputResponses via 'tasks/update', keyed to the outstanding inputRequests. The server acknowledges with an empty result and ignores responses for unknown or already-satisfied keys.
11. Request cancellation with 'tasks/cancel'. The server acknowledges with an empty result but cancellation is cooperative — the task may still reach a non-cancelled terminal status.
12. To avoid polling, opt into 'notifications/tasks' through subscriptions/listen. Each notification carries full task state, so no extra tasks/get round trip is needed. Polling remains the default.
13. Degrade gracefully: if one side lacks the extension, fall back to core protocol behavior, or reject the request with an appropriate error if the extension is mandatory for that operation.
14. Verify: drive a long operation to completion by polling, then again via notifications, then confirm tasks/cancel is acknowledged and that a client which did not declare the extension never receives a task handle.