The complete MCP media-generation job lifecycle

Start with discovery and a cost preflight

A complete media-generation lifecycle begins before submission. The current OfflineCreator package separates list_models and get_credits so an agent can inspect workflows, published credit costs, and the account balance before reserving work. The operator should choose the model, aspect ratio, prompt, and source rights at this stage instead of treating a generation call as an unbounded experiment.

The current MCP tools specification defines discovery through tools/list, which returns each tool's name, description, input schema, and optional behavior annotations. That protocol-level registry makes preflight inspection possible, but it does not guarantee that every client refreshes a changed tool list at the same time.

For image-to-video, upload_input adds a source image under the configured upload root before submission. The package documents extension, size, magic-byte, and path-jail checks for local uploads. These checks narrow local file access; they do not certify that the user owns the source or that the resulting media is suitable for publication.

Retrieve the completed output through the owner boundary

Completion is not the same as delivery. download_output returns a short-lived signed URL for a completed output, and the product page describes authenticated private media delivery. A workflow should confirm the terminal state, download to an approved destination, preserve relevant provenance, and avoid placing signed URLs in durable logs or public messages.

The buyer's acceptance record should contain the model and published cost seen at preflight, the submission time, returned identifier, every observed state, poll stop reason, cancellation attempt if any, final balance, and output retrieval result. That record reveals duplicate-submission and refund gaps that a simple successful demo would miss.

Track one job instead of submitting duplicates

The generate tool starts work, while get_generation reads the current state and wait_generation performs bounded polling. list_generations helps reconcile recent account history after a transport timeout. Retain the returned job identifier and check status before retrying; a lost client response is not evidence that the provider never accepted the request.

Cancellation is a separate lifecycle action. The published package describes cancel_generation as canceling an eligible reserved job and refunding its credits. A provider failure is also described as returning reserved credits automatically. This research did not execute a live cancellation or failure, so the draft records the documented contract without claiming measured timing or universal provider behavior.

Define terminal handling before launch. A completed job proceeds to owner-authorized retrieval. A failed job triggers balance reconciliation before replacement. A cancellable reserved job can use the documented cancellation path, while a job that is already beyond that eligibility must be observed to a terminal state rather than repeatedly canceled. The package contract supports those decisions, but no posting-time promise is inferred.

Design the timeout path before the happy path

A timeout can occur after a service has accepted work but before the client receives the response. Treat that as an unknown outcome, not an automatic failure. Persist the generation identifier whenever it is available, then use get_generation or list_generations to reconcile the account before another submission. If the identifier never reached the client, compare recent jobs against the approved model, prompt, and submission window rather than immediately spending credits on a duplicate.

Bounded waiting and one-time status checks serve different operator needs. wait_generation is useful when the caller can remain attached for a defined interval; get_generation is safer for a scheduler or a user returning later. In either case, stop polling after the documented bound, surface the last known state, and let a person choose whether to continue, cancel, or investigate. The presence of a wait tool does not establish a latency promise.

Close the lifecycle only after the output is downloaded to an approved location and the account record shows the expected terminal state. If cancellation or provider failure is involved, check the credit balance rather than assuming the documented refund has already posted. The first-party sources support the available lifecycle tools and signed-delivery contract, while this draft deliberately avoids a timing claim because no live failure exercise was performed.

Related reading