Migrate OfflineCreator from stdio to remote MCP

Follow the boundary that blocks cutover

Return to the comparison directory if you still need to choose among access patterns. Use the API-key-to-OAuth migration when secret removal is the main task but local process execution is not. Use the provider-to-REST migration when the application, rather than an MCP client, owns model IDs, job states, and retrieval. These routes separate authentication, transport, and API-contract decisions instead of treating them as one migration.

Account for credentials and local-file access separately

The stdio fallback requires a personal API key in `OFFLINECREATOR_API_KEY`; the published @offlinecreator/mcp package configuration defines `OFFLINECREATOR_UPLOAD_ROOT` as the directory that `upload_input` paths must remain inside (defaulting to the process cwd). The remote configuration published for supported clients contains the canonical URL rather than a copied Studio key. Live protected-resource metadata currently advertises `models`, `read`, and `generate`, while the authorization-server metadata advertises authorization-code and refresh-token grants with S256 PKCE.

Removing the local package also removes the exact package-side filesystem boundary that was verified in its README. Public documentation lists `upload_input` in the package's tool catalog, but this research did not capture an authenticated hosted `tools/list` response or prove that the hosted tool can read a path on the client machine. Treat local-path upload behavior as an explicit migration gap: test the actual source-image workflow before retiring stdio.

OAuth changes where the reusable Studio API key is configured; it does not prove that a client stores tokens securely or that old secret copies disappeared. After the remote path passes, remove the stdio entry and its environment reference according to your own secret-management process. Do not place a fallback key in the remote URL, logs, chat, or source control.

Credential check

Remote entry has a URL and no copied API keyComplete consent in the browser and verify the expected Studio account and scopes.

Filesystem check

Source-image behavior remains unverified until exercisedDo not assume a hosted server can resolve the same local path accepted by the stdio package.

Verify documented operations instead of claiming full parity

The published @offlinecreator/mcp 0.1.2 README presents one nine-tool catalog alongside its remote OAuth and stdio setup instructions: `list_models`, `get_credits`, `generate`, `upload_input`, `get_generation`, `wait_generation`, `download_output`, `cancel_generation`, and `list_generations`. That is documentation-level evidence of the intended operation surface, not an authenticated comparison of the two live connections. This draft therefore does not claim complete tool, schema, error, upload, cancellation, or output-delivery parity.

Run a staged acceptance check in the client that will own the remote connection. Record the client build and package version first. Connect the canonical URL, inspect the returned tool names and schemas, then call low-risk reads such as model and credit lookup. If the workflow creates media, verify one approved generation through status and output retrieval. Test cancellation only on an eligible expendable job, and test `upload_input` with a rights-cleared disposable image before deleting the local fallback.

One recent GitHub pull request offers a limited practitioner anecdote: the Lazyweb project replaced an `mcp-remote` stdio bridge with native Streamable HTTP for Codex and added a regression test intended to preserve neighboring configuration. It concerned another MCP service, used a bearer header rather than OfflineCreator OAuth, and showed only one reaction. It supports testing a targeted config replacement, but it does not establish broad adoption, OfflineCreator compatibility, or equal tools.

Documented overlap

Nine named tools appear in the package READMEUse the live authorized tool list, not this static list, as the cutover gate.

Unverified boundary

Hosted local-file upload and exact schemasPreserve stdio until the source-image workflow is observed in the target client.

Anecdotal migration signal

One unrelated project moved from a stdio bridge to native HTTPUseful as a config-preservation test idea, not as product or market proof.

Move the connection, not the workload

OfflineCreator's current migration path replaces a client-launched `npx -y @offlinecreator/mcp` process and `OFFLINECREATOR_API_KEY` environment entry with the hosted URL `https://mcp.offlinecreatorstudio.com/mcp`. The remote entry uses browser OAuth; the first-party setup page says no API key is stored in the client file. Keep the stdio entry intact during acceptance testing so rollback does not require reconstructing a deleted command or secret reference.

This is a transport and credential migration, not a change from local generation to cloud generation. The MCP specification defines stdio as newline-delimited JSON-RPC over a client-launched subprocess and Streamable HTTP as HTTP requests to one MCP endpoint. OfflineCreator separately states that both MCP paths reach Studio's cloud workflow and that generation inputs go to the disclosed cloud provider selected for the model.

Choose remote MCP when the client supports the hosted URL and OAuth flow and you want to stop operating a local MCP subprocess. Keep stdio when the client lacks compatible remote authentication, when a controlled local package version is an operational requirement, or while a filesystem-input workflow remains unverified on the hosted connection. Neither choice establishes better output quality, latency, reliability, privacy, or cost.

Before

Client launches @offlinecreator/mcp and supplies OFFLINECREATOR_API_KEYThe local process communicates over stdio and the package calls the Studio cloud API.

After

Client connects to https://mcp.offlinecreatorstudio.com/mcpA compatible client discovers OAuth, opens browser sign-in, and uses bearer credentials after authorization.

Rollback

Preserve the old stdio entry until observed operations passDo not infer parity from the shared product name or from protocol-level transport semantics.

Evidence and editorial boundary

This page owns the staged migration from OfflineCreator's local stdio package to its hosted remote MCP endpoint. It does not own a general OAuth-versus-key comparison, client-specific configuration, model benchmarking, pricing, provider migration, or the claim that remote and stdio are fully equivalent. Consolidate it into the comparison directory if current transport setup and a meaningful parity check can no longer be maintained.

Recent community retrieval returned one qualified migration-pattern anecdote and no OfflineCreator-specific adoption evidence. Missing or partial source coverage is preserved as a research gap and must not be interpreted as evidence of silence. The qualified Lazyweb pull request concerns another service and bearer-header authentication; it does not establish OfflineCreator compatibility, tool parity, reliability, security outcomes, performance, or migration success rates.