Image and video generation tools for developers using MCP

Prove one developer path before adding creative tools to an agent

Start with a narrow acceptance path: discover the tools, list the current models, inspect the credit balance, submit one low-risk image prompt, poll the returned generation identifier, and retrieve the completed output. The published `@offlinecreator/mcp` 0.1.2 package exposes nine separate tools for model discovery, credits, generation, source-image upload, status, waiting, output download, cancellation, and recent-job listing. Those boundaries give application code an explicit place to validate inputs, stop after a failure, or require approval before another paid action.

Do not begin by wiring every media workflow into an autonomous loop. Use a synthetic prompt with no customer data, select a visible model and cost, and save the tool arguments and result status in a test fixture. A successful connection is not a quality benchmark: the proof should establish only that the intended client can discover the authorized tools, make one bounded call, receive a terminal status, and hand the output to a human reviewer.

Keep OAuth, tool authority, and cloud processing separate

For a supported remote client, OfflineCreator currently recommends `https://mcp.offlinecreatorstudio.com/mcp`: add the URL, choose Connect, and complete Studio sign-in in the browser. Its product page says no API key is stored in the file, and its live protected-resource metadata names the same resource and advertises `models`, `read`, and `generate` scopes. Scope visibility is an authorization boundary, not permission for an agent to generate without the operator's approval.

OAuth also does not make generation local. OfflineCreator identifies MCP and CLI as interfaces to its cloud Studio service and says generation inputs go to the disclosed provider for the selected model. Keep secrets, production data, private source media, and unapproved customer material out of the first proof. If image-to-video is required later, review the upload boundary separately instead of assuming an image prompt and a local file have the same exposure.

Put a visible credit gate before generation

Treat model discovery and balance inspection as preconditions, not optional diagnostics. OfflineCreator's current product page says model costs remain visible before generation and lists six launch costs: 1 credit for FLUX Schnell, 5 for Recraft V3, 8 for FLUX 1.1 Pro Ultra, 42 each for Kling 2.6 Pro and Kling 2.6 Pro Motion, and 96 for Veo 3.1 Fast. These are current first-party catalog facts, not a promise that a model will meet a brief or remain available at that cost.

In a developer-controlled flow, capture the model identifier and displayed cost at approval time, set a test budget, and reject an unexpected catalog or balance response before calling `generate`. Re-read the live catalog for production rather than hard-coding this page's snapshot. This draft did not spend credits or test refund behavior, so it makes no claim about real output quality, completion time, reliability, or total cost for a usable asset.

Choose the workflow before the model

Text to image

One composition proofUse a non-sensitive prompt and a low test budget to verify model discovery, generation, status polling, and output retrieval before attempting a batch.

Text to video

One short motion proofSpecify one subject action and one camera behavior, then require a human review gate because a valid tool result does not establish visual continuity or production readiness.

Image to video

Separate upload reviewConfirm rights and sensitivity before sending a source image; the published tool sequence reserves a generation, uploads the input, submits it, and then waits for status.

Higher-cost model

Fresh catalog checkRead the current model list and cost immediately before approval instead of treating a stored model name or this research snapshot as durable configuration.

Test the MCP adapter, not an imagined replacement API

MCP and a provider API are different integration surfaces. The current MCP architecture defines a client-server protocol through which an AI application discovers schema-described tools and invokes them with `tools/list` and `tools/call`. In the published OfflineCreator package, those MCP handlers call a Studio client that sends requests to `/api/v1/models`, `/api/v1/credits`, and `/api/v1/generations`. MCP supplies discovery and model-facing tool schemas; the Studio API remains the service boundary that performs account and generation operations.

That distinction matters when deciding where to integrate. Use MCP when an existing agent host should discover a bounded tool set and a human can inspect proposed calls. Use the direct API when application code needs an API-native workflow outside an MCP host. The published 0.1.2 package documents nine MCP tools and a thin CLI limited to `models`, `balance`/`credits`, and `generate`; its README says the public package ships the thin API client, stdio MCP server, and oauth-bridge while the hosted API, OAuth Worker, moderation, account, credit, and generation backend remain proprietary. Do not claim that connecting MCP creates a general-purpose SDK, exposes every Studio backend capability, or authorizes an agent to charge a payment method.

Continue from the next engineering decision

Open the creator-use-case directory if the intended media outcome is still unclear. Use the design-concept page when the main problem is composition and brand-direction review, or the automation-engineer page when the workflow needs bounded status, cancellation, output, and spend handling. These routes keep this page focused on the developer integration decision: OAuth connection, authorized tools, an explicit API boundary, and one observable acceptance test.

Evidence boundary for developer adoption and outcomes

Editorially, this page does not use community anecdotes to characterize developer adoption, preferences, reliability, speed, output quality, or cost efficiency. Those topics remain outside the evidence boundary of this draft, and the absence of a claim here should not be interpreted as evidence for or against developer interest.

Keep the page limited to claims that have current citations to product, package, implementation, metadata, or protocol sources. Client compatibility, generation behavior, revocation behavior, and production suitability still require hands-on engineering verification before an editor can present them as observed outcomes.