An operational checklist for MCP creative generation
Cover scopes, budgets, inputs, retries, cancellation, downloads, and incident revocation.
Get practical MCP creation notesRun creative generation as an approved operation, not an open-ended prompt
An MCP creative operations checklist should define the run before an agent calls a generation tool. Record the intended deliverable, approved model, aspect ratio, input source, candidate count, maximum credit spend, wait deadline, and the person who can stop or revise the run. Then expose only the tools needed for that plan. The current MCP tools specification recommends a human in the loop who can deny invocations, clear indicators when tools run, and confirmation prompts for sensitive operations.
For OfflineCreator specifically, the current published package lists separate tools for models, balance, generation, input upload, status, waiting, output retrieval, cancellation, and recent jobs. Those distinct operations make a staged runbook possible: inspect first, approve cost and input, submit once, reconcile by generation ID, and retrieve the completed output. Tool discovery is not approval to spend, and a successful submission is not proof that the media finished or that a download was preserved.
- Approve
- Deliverable, model, ratio, candidate count, and spend ceilingStop before submission when the selected model or published cost differs from the approved plan.
- Execute
- One identified generation at a timeRetain the returned generation ID before waiting, retrying, cancelling, or downloading.
- Close
- Verified output or a recorded stopped stateA timeout, cancellation request, or signed URL is an intermediate fact, not automatic completion.
Preflight scopes, cost, inputs, and stop conditions
Start with least privilege. The 2026-07-28 MCP authorization specification tells clients to request only the scopes needed for intended operations and to treat a server's scope challenge as authoritative for the current operation. OfflineCreator's public package maps model listing to `models`, status and output operations to `read`, and generation, upload, and cancellation to `generate`. A review-only session therefore should not receive generation permission merely because a later production session might need it.
Next, obtain current model and credit information at the point of use. OfflineCreator's public MCP page says model costs are visible before generation and that web, MCP, CLI, and API calls use the same account credit balance and published per-model costs. This draft does not freeze those numbers into a runbook. Record the returned model ID and displayed cost, multiply by the approved candidate count, preserve a reserve for deliberate revisions, and stop for human review if the balance or catalog no longer matches the plan.
Finally, validate rights and operational constraints before uploading. Confirm that the source media may be disclosed to the selected cloud provider, that the prompt complies with the current acceptable-use policy, and that the required format and ratio are documented. The policy allows agent use only within its rules and published rate limits, makes the account holder responsible for agent requests, and prohibits sharing or pooling credentials. A checklist cannot turn an undocumented limit or an unreviewed asset into an approved input.
- Scope gate
- Grant only models, read, or generate as requiredUse step-up authorization for a newly required operation rather than starting every session broadly privileged.
- Budget gate
- Current displayed unit cost × approved attemptsDo not infer current prices, balances, refunds, or quotas from an old run.
- Input gate
- Rights, policy, provider disclosure, type, size, and ratio checkedIf any required fact is missing, return the asset to a person instead of guessing.
Make submission a single auditable decision
Immediately before `generate`, show the operator the exact model, prompt or approved prompt reference, aspect ratio, input requirement, unit cost, planned attempts, and maximum total spend. The MCP tools specification recommends showing tool inputs and prompting for confirmation on sensitive operations. This checklist treats generation as the spend-approval boundary; that is an operational control for this workflow, not a universal MCP rule or proof that any particular call reserved credits. Never let a model silently enlarge the candidate count, switch to a more expensive model, or substitute a different source asset after approval.
After the call, preserve the response and classify its operation state as rejected, accepted with a generation ID, or unknown because the response was lost. Do not log bearer tokens, personal API keys, complete private prompts, source media, or signed output URLs. If the server rejects the call before a generation exists, correct only the documented error. If the state is unknown, inspect recent jobs or reconcile using a known identifier before submitting the prompt again; an immediate replay could create a second paid job.
- Confirmation record
- Approved arguments, cost basis, UTC time, and operatorKeep the record small enough to audit without copying private media or credentials.
- Submission record
- Tool result, safe correlation data, and generation IDThe durable identifier supports status checks after a client disconnect or local timeout.
- Unknown state
- Reconcile before replayA missing response does not establish that the provider never received the job.
Bound waiting, retries, and cancellation separately
Status polling and generation submission are different operations. Keep the generation ID, use the status or wait tool, and end the wait at a declared deadline. OfflineCreator's public client currently polls every 1.5 seconds by default, returns when status is completed or failed, and returns the latest state with `timedOut: true` after the local bound. Its public tool schema permits `wait_generation` bounds from 5 to 300 seconds. A timed-out wait is therefore not evidence that the generation failed and is not permission to submit a duplicate.
Retry only the boundary that failed. Invalid arguments need corrected input; insufficient scope needs bounded authorization; insufficient credits need a human budget decision; and rate limiting needs server guidance or capped backoff. For current OfflineCreator compatibility tools, `cancel_generation` is described as cancelling a reserved generation before provider submission and refunding credits. Do not promise cancellation after provider submission, and do not assume a cancellation request has succeeded until the returned state confirms it.
Protocol-level MCP Tasks has a broader cooperative cancellation model: `tasks/cancel` acknowledges intent but does not obligate the server to stop work, and a task can reach another terminal state. OfflineCreator's published package documents ordinary generation tools around `generationId`, not negotiated Tasks support. Keep those contracts separate so a generic task example does not become a false product guarantee.
- Wait
- Poll one known generation until completion, failure, or deadlinePreserve the latest state when the local waiting window ends.
- Retry
- Repeat only a documented safe operationNever treat every timeout or error as a failed submission.
- Cancel
- Request within the documented eligibility windowReconcile the final state and credit result rather than inferring both from intent.
Download promptly, preserve provenance, and prepare revocation
When status is completed, retrieve the output through the documented read operation. OfflineCreator's current package says `download_output` returns a short-lived signed URL, expiry metadata, and content type without streaming media bytes into model context. Download before the returned expiry, verify the response and content type, and store the approved asset in its intended controlled destination. Retain the generation ID, model, settings, creation time, review decision, and transfer result; discard the bearer URL from prompts, tickets, analytics, and long-lived manifests.
If the URL expires, use the authorized generation ID to request current output metadata rather than editing the URL or regenerating the asset. If a credential or link may have leaked, stop new submissions, remove it from shared systems, and revoke the affected credential. OfflineCreator's public MCP page says OAuth connections can be revoked from Settings, and its privacy policy says individual or all personal API keys can be revoked there. Revocation does not prove that an already downloaded file vanished, so separately assess recipients, published copies, account history, and underlying media retention.
Close the run only after the output has a named owner and disposition: approved and stored, rejected and retained under policy, or scheduled for deletion. Record incident-safe metadata rather than raw secrets or private content. A successful HTTP transfer establishes that one client received bytes; it does not establish creative approval, rights clearance, publication, deletion from the service, or removal of downstream copies.
- Retrieve
- Completed generation plus current expiry metadataUse the signed link for immediate delivery, not as the durable identity of the work.
- Preserve
- Generation ID, settings, decision, checksum if available, and storage locationDo not claim a cryptographic provenance guarantee unless the workflow actually creates and verifies one.
- Revoke
- Disable the exposed connection or key and investigate distributionCredential revocation, signed-link expiry, unpublishing, and media deletion are separate controls.
Choose the next guide from the boundary that failed
Use the provenance guide when the asset completed but its model, prompt reference, settings, timestamps, and review trail are incomplete. Return to the learning center when authorization, tool discovery, generation state, and media delivery still need to be separated. This page owns the operational sequence across those boundaries; it does not replace current model documentation, a rights review, an incident response plan, or a product-specific limit table.