MCP tools for creative agents that generate real media

Give a creative agent a bounded tool surface

OfflineCreator's immutable public v0.1.2 source registers nine MCP tools. The models group contains list_models; read contains get_credits, list_generations, get_generation, wait_generation, and download_output; generate contains generate, upload_input, and cancel_generation. When scopes are supplied, server registration omits tools outside them; without supplied scopes, including local stdio, the code registers all nine. This is the verifiable public tool surface evaluated here.

That separation lets an orchestrator plan an explicit sequence: inspect the catalog, confirm cost and balance, collect an approved prompt or source image, submit once, retain the job identifier, wait within a bound, and retrieve the result. The agent should not infer source rights, brand approval, or publication permission from tool availability. Those are human decisions outside the transport.

Keep purchasing and publication under human control

The immutable public nine-tool registry contains no purchasing, top-up, or Checkout tool. That verifies only the MCP boundary; neither the public server source nor README documents a human-browser Checkout flow. Buyers should verify how purchasing is initiated and confirmed in deployment before granting generation authority. Payment behavior was not runtime-tested here today.

A practical approval gate should show the selected model, published credit cost, prompt, aspect ratio, source asset, and intended destination before submission. A second review should inspect the completed media before download or publication. Recent Reddit evidence discussed smaller MCP tool registries and context costs, but it was uncorroborated and cannot establish OfflineCreator quality, adoption, or measured workflow outcomes.

Evaluate permissions by stage. A planning agent can receive the models scope for catalog discovery. An observer can receive read for balance, status, waiting, downloads, and recent jobs. An executor can receive generate for submission, source-image upload, and cancellation. The public implementation maps those scopes during registration, but buyers should verify the deployed authorization path and visible registry before relying on this separation operationally today.

Evaluate the orchestration failure paths

Test how the chosen client handles an uncertain submission, low balance, provider failure, waiting timeout, and revoked authorization. Before retrying, require an operator decision based on whatever state the deployed client can actually retrieve. Define local rules for credential storage and log redaction. These are buyer-authored acceptance requirements, not verified behavior of every client or deployment.

An acceptance plan can simulate a lost response, a polling timeout, low balance, and revoked access. The pass criteria can require reconciliation before resubmission, a stop instead of autonomous purchasing, preservation of operator-visible state, and refusal to continue after revocation. These criteria apply the MCP specification's human-denial guidance; they do not claim that OfflineCreator or any client enforces them automatically.