MCP Tasks for long-running image and video generation
Explain durable task handles, polling, updates, cancellation, and how they differ from Studio's current compatibility pattern.
MCP Tasks is an opt-in extension for asynchronous work. A supporting server can return a durable task handle instead of holding a request open until a long-running operation finishes. The client keeps the taskId and can resume polling after a disconnect or restart. A completed task carries the original result, a failed task carries a JSON-RPC error, and cancelled is a distinct terminal outcome without a promised result or error. For queued image or video work, use this as the protocol model only when both peers actually support the extension.
Task creation is server-directed for each eligible request. A supporting client must be prepared for either an ordinary result or a CreateTaskResult with resultType set to task. The returned Task includes its taskId, initial status, ttlMs, and pollIntervalMs, and the server is required to make the task durably findable before returning that handle. Whether a particular media server implements these requirements must be verified separately.
- Handle
- taskIdPersist it so polling can resume after a client or connection failure.
- Initial response
- resultType: taskCarries status, time to live, and the server's suggested polling interval.
- Final response
- completed, failed, or cancelledCompleted carries the original result; failed carries a JSON-RPC error; cancelled is a separate terminal status.
Separate MCP Tasks from OfflineCreator's current compatibility tools
OfflineCreator's published package documents ordinary tools around a Studio generationId: generate starts work, get_generation reads status, wait_generation polls within a bound, and cancel_generation requests an eligible cancellation. The generate tool also accepts wait: true. These sources establish that compatibility surface; they do not independently establish whether any deployed endpoint also negotiates io.modelcontextprotocol/tasks. Treat protocol-level Tasks support as unverified until capability discovery and protocol tests prove it.
The public source makes the distinction concrete. Its client polls the generation status every 1.5 seconds by default, returns on completed or failed, and returns the latest status with timedOut after the wait bound. The tool schema allows wait_generation bounds from 5 to 300 seconds. Its cancellation tool is narrower than generic Tasks cancellation: the description limits it to a reserved generation before provider submission. A caller should preserve the generationId after a wait timeout and reconcile status instead of treating timeout as failure or blindly creating another render.
- Current Studio handle
- generationIdPass it to the package's status, wait, download, or eligible cancellation tools.
- Current wait
- tool-owned polling loopThe tool returns a normal MCP result after completion, failure, or its local timeout.
- Tasks migration
- not establishedDo not rename generation tools or claim extension support without negotiated capabilities and protocol-level tests.
Keep the evidence boundary visible
The protocol claims on this page follow the 2026-07-28 changelog and current Tasks extension documentation retrieved on August 9, 2026. The extension documentation and changelog describe Tasks as an official opt-in extension, while the ext-tasks repository README still labels the repository experimental and not official. The community-maintained extension support matrix retrieved the same day lists MCP Apps and auth extensions but does not list Tasks, so named client support remains unverified. Pin implementation work to a dated specification and recheck the repository and matrix before shipping.
The product comparison here is source-level, not a live generation acceptance test. The published @offlinecreator/mcp 0.1.2 package and public server test verify package-version metadata and annotations for nine tools, including a destructive hint on cancel_generation. That test file contains no live provider render or protocol-level Tasks negotiation case. Treat reconnection, mid-flight input, deployed client support, and cancellation after provider submission as unverified; this draft makes no reliability, adoption, output-quality, or compatibility claim.
Follow the Tasks lifecycle without inventing a job API
After creation, tasks/get is the default observation path. A client should respect pollIntervalMs because the server may change that value over the task's lifetime or rate-limit faster polling. Working means the operation is still running. Completed, failed, and cancelled are terminal states. Input_required is different: the task is paused on client input, and the client answers the outstanding inputRequests through tasks/update before polling continues.
Cancellation is a request, not a guarantee. tasks/cancel acknowledges cancellation intent, but work may remain non-terminal for a time or may finish in another terminal state. The generic notifications/cancelled message is not the task-cancellation method. A server can publish full task-state updates through notifications/tasks when the subscription mechanism is in use, but clients still need a correct polling path unless notification support has been established.
- Observe
- tasks/getPoll with the returned taskId and honor the latest pollIntervalMs.
- Respond
- tasks/updateSupply responses only for outstanding input requests.
- Request a stop
- tasks/cancelTreat the acknowledgement as cooperative intent, then continue reconciling state.
Negotiate the extension before returning a task
Tasks is not an automatic feature of every current MCP connection. The client includes io.modelcontextprotocol/tasks in its extension capabilities on each modern request, and the server advertises the same identifier in server/discover. A server must not return a task handle to a client that did not declare support. If only one side supports the extension, it must fall back to core behavior or reject the operation with an appropriate error.
This boundary matters during migration. The 2026-07-28 changelog moved the earlier experimental Tasks design out of the core protocol into the io.modelcontextprotocol/tasks extension. It removed tasks/list and the blocking tasks/result method, added tasks/update, and made tasks/get the polling and result-retrieval path. Treat compatibility with the older 2025-11-25 shape as unverified until a client and server negotiate and exercise the current extension.
- Extension identifier
- io.modelcontextprotocol/tasksBoth client and server must declare support.
- Current retrieval
- poll tasks/getDo not copy the older blocking tasks/result flow into a current implementation.
- Unsupported peer
- fallback or errorNever send a task-shaped result to a client that did not opt in.
Choose the next concept by the boundary you need
Return to the learning center for the broader MCP image-generation map. Read the tool-scope guide before deciding which status, read, or generation operations a client should see. Use the payment-boundary lesson when a workflow can spend credits or surface a browser Checkout step. A taskId is documented as an execution-state handle; do not treat possession of that handle as proof of authorization, budget approval, source rights, or payment consent.