Human-approved creative automation with MCP

Put approval at the side-effect boundary, not at the end

Human-approved creative automation means an agent may prepare work, but a named reviewer decides whether a specific side effect may occur. For this workflow, place separate gates before a paid generation call, before an asset leaves the working area for client delivery, before any publication handoff, and before an irreversible change such as overwriting the only approved source. Approval of a brief is not blanket approval of every later prompt, ratio, retry, destination, or revision.

The current MCP tools specification describes tools as model-controlled, yet recommends a human in the loop who can deny invocations. It also recommends showing which tools are exposed, indicating when a tool is invoked, and presenting confirmation prompts for operations. The protocol does not prescribe a particular interface, so the host application and operating procedure must turn that guidance into a real stop: the reviewer must be able to inspect the pending action and decline it before execution.

Use the smallest approval object that captures the decision: action, tool, exact inputs, expected cost or resource effect, output destination, approver, timestamp, and expiry. If any material field changes, invalidate the approval. This prevents a benign approval for one square concept from silently authorizing a batch, a different model, a source-image upload, a client send, or a public post.

Prepare

Agent drafts and validates the requestNo spend, delivery, publication, or destructive write is permitted in this stage.

Approve

Reviewer sees the exact pending side effectApproval binds to named inputs, destination, limits, and an expiration.

Execute

One bounded action runsThe result and tool response return to review instead of triggering the next risky step automatically.

Classify creative tools before deciding what can be pre-approved

Build a tool inventory around effects rather than friendly names. Discovery and status reads can usually sit in a low-risk lane. Uploading a source image changes the disclosure boundary. Starting generation crosses a credit-reservation boundary. Downloading a completed asset moves data into another workspace. Client delivery, publication, deletion, replacement, and account changes belong in separate lanes even when a single agent conversation can reach all of them.

Do not use an MCP tool annotation as the authorization decision by itself. The current specification says clients must treat tool annotations as untrusted unless they come from trusted servers. A host can use annotations to improve labels, but approval policy should also match an allowlist of server identity, tool name, input schema, credential scope, destination, and permitted effect. Unknown or changed tools should fall back to blocked or per-call review.

Keep automation useful by pre-approving only narrow reads with bounded inputs, such as listing available models or checking one generation status. Require fresh confirmation for spend, external disclosure, public release, and destructive changes. The distinction is not whether an action feels creative; it is whether the action consumes funds, exposes data, affects another party, or is difficult to reverse.

Read lane

Catalog, balance, status, and recent-job checksAllow only from a trusted server with bounded responses and no downstream action.

Spend lane

Generation, paid retry, or provider submissionRequire the current model, prompt, ratio, maximum calls, and displayed cost context.

Disclosure lane

Source upload, client delivery, or public handoffRequire source authorization, destination, audience, and the exact files or fields leaving the workspace.

Irreversible lane

Delete, overwrite, revoke, or publishUse one-action confirmation and retain enough information to investigate or recover where recovery is possible.

Make the confirmation screen evidence-bearing

A useful confirmation states what will happen, not merely that a tool wants permission. Show the trusted server and tool identity, normalized inputs, model and workflow, prompt or prompt hash, source-file name, target ratio, maximum calls, destination, and what cannot be undone. Hide secrets while preserving enough context for the reviewer to recognize the request. Reject an approval when the runtime inputs differ from the displayed values.

The MCP tools specification assigns controls to both sides of the connection. Servers must validate tool inputs, implement access controls, rate-limit invocations, and sanitize outputs. Clients should ask for confirmation on sensitive operations, display tool inputs before the call, validate tool results before returning them to the model, use timeouts, and log tool usage for audit. Human review is one control in that chain, not a substitute for server enforcement or client validation.

After execution, compare the response with the approved action. A generation identifier is not creative approval; a completed status is not permission to deliver; and a signed download URL is not evidence that the asset is safe, accurate, licensed, accessible, or on-brand. Route the actual output through a review rubric, then create a new approval record for the next side effect.

Apply the gates to the current generation tool boundary

The published @offlinecreator/mcp 0.1.1 package exposes nine tools: model listing, credit lookup, generation, source-image upload, generation status, waiting, completed-output download, cancellation, and recent-generation listing. Its compiled server groups those tools into models, read, and generate scopes. The package does not enumerate a campaign-approval record, client-delivery, or publishing tool. Treat approval records and downstream handoffs as controls in your host or production system, not as Studio features.

For a text-to-image proof, let the agent call the catalog and balance reads first. It can then prepare an approval request containing the chosen model ID, exact prompt, aspect ratio, maximum call count, and the reviewer’s pass condition. Only after approval should it invoke generate once. Return the output for visual, factual, rights, and brand review. A rejected proof does not automatically authorize a retry, because changing the prompt or buying another call changes the approved inputs or spend.

For image-to-video, add a disclosure gate before upload. The package documents upload_input as attaching a source image to a reserved generation and submitting it to the provider. Confirm that the file is the approved source, sits within the intended upload root, may be sent to the disclosed cloud workflow, and matches the generation identifier. Approval to generate motion is not permission to substitute a different local image.

Before spend

Approve one model, prompt, ratio, and call ceilingLive catalog and balance reads inform the decision but do not make it.

Before upload

Approve one source file and one reserved generationCheck source rights and the external processing boundary before disclosure.

Before handoff

Approve the reviewed output and named destinationA completed generation remains a draft until the destination-specific review passes.

Keep credentials narrower than the approval conversation

Human confirmation cannot repair an overpowered credential. Give discovery and read operations a minimal initial scope, then request an additional capability only when a reviewed action needs it. Current MCP security guidance recommends a progressive, least-privilege scope model with low-risk discovery or read operations first and targeted elevation for additional permissions. Expire elevated access when the bounded task ends instead of turning one approved generation into standing generate authority.

Keep token audiences explicit across every service boundary. The current authorization security considerations require MCP clients to include the resource parameter in authorization and token requests, require servers to validate that tokens were issued for them, and forbid forwarding the client’s token to an upstream API. If the MCP server calls a provider, it must use a separate upstream token. These controls reduce the chance that a legitimate credential for one service is replayed against another.

Record which identity, server, scope, and tool were authorized without logging the secret itself. Review repeated denials, unexpected scope challenges, input changes after confirmation, and attempts to reach unapproved destinations. Pause the workflow when the server identity, tool schema, audience, or required scope changes; those are security-relevant changes, not routine prompt edits.

Choose the next page from the unresolved control

Use the creator-use-case hub when the team has not chosen a generation outcome. Move to codebase media completion when the approved asset must be optimized and patched into a project with repository review. Use creative proof-set operations when the next question is how many controlled variants to produce and when to stop or scale. Those pages handle adjacent decisions; this page owns the approval boundary before spend, disclosure, delivery, publication handoff, and irreversible change.

Evidence limits and approval boundary

The real last30days v3.18.4 run returned 98 items and was degraded: X credentials were not configured, Reddit ended partial after RedditRSS feed failures with keyless recovery (14 items), and arXiv, Polymarket, and Techmeme returned no results. Every evidence cluster scored zero. Four items were classified relevant—an essay on creative-agent human approval, a human-in-the-loop fatigue article, reporting on unsanctioned agent actions after safeguards were removed, and a Reddit MCP security-horror thread—but those remain untrusted adjacent anecdotes. This draft therefore cannot claim community consensus, adoption, preferred approval interfaces, fewer incidents, savings, speed, creative quality, conversion, or customer outcomes.

The supported guidance is limited to the current MCP tools and authorization specifications plus the public, version-pinned @offlinecreator/mcp 0.1.1 package. MCP recommends human oversight but does not mandate one approval UI. The 0.1.1 package lists generation workflow tools but not an approval-record, client-delivery, or publishing tool. The npm registry also lists 0.1.2 with the same public tool names; product claims here stay pinned to the verified 0.1.1 README and compiled server. The approval object, policy engine, reviewer assignment, delivery integration, and publication control described on this page are workflow designs that an implementation must supply and test.

No authenticated Studio account was connected, no private balance was read, no source was uploaded, no credits were spent, no output was generated, and no client or publishing destination was exercised. Refresh the product surface and current MCP security version before operational use. Keep this page as an unreviewed draft until editorial and security reviewers verify that each proposed gate matches the actual host, server, credentials, destinations, and recovery procedures.