Remote OAuth MCP vs local stdio for OfflineCreator

Diagnose the failure at the transport boundary

A remote connection failure should be split into HTTP reachability, authorization discovery, consent, token, and scope checks. The MCP authorization specification requires bearer tokens in the Authorization header on every protected HTTP request and forbids tokens in query strings. It distinguishes 401 for missing, invalid, or expired authorization from 403 for insufficient permissions. Do not move a key into the URL to work around either result.

A stdio failure has a different first check: can the client launch the configured command and keep valid MCP messages on stdout? The stdio specification reserves stdout for newline-delimited JSON-RPC and allows logs on stderr. If the child exits unexpectedly, the specification recommends that the client restart it, but in-flight work is lost. Check the package command, Node environment, secret injection, stderr, and working directory before treating that symptom as a Studio service outage.

Image-to-video adds a path-specific failure mode under stdio. Current OfflineCreator package security documentation states that local file uploads are jailed under OFFLINECREATOR_UPLOAD_ROOT, extension-allowlisted, size-limited, and checked by image magic bytes, and that remote MCP has no local filesystem access. Expand the approved root only to the intended source directory; do not remove the boundary. Operators using remote OAuth should not assume that a local path string is uploadable.

Read common symptoms without switching transports blindly

A 401 from the hosted endpoint points to authorization that is absent, invalid, or expired; a 403 can indicate an insufficient scope or an invalid HTTP Origin. Those conditions have different remedies. Reauthorize or refresh for a token problem, request the needed scope for an insufficient-scope response, and verify the configured endpoint and client origin when transport validation rejects the request.

For stdio, ordinary diagnostic text on stderr is not itself an MCP error. Text on stdout is different: the protocol requires every stdout line to be a valid MCP message. A process that exits, a missing executable, malformed stdout, or a package that starts in the wrong working directory belongs to local launch diagnostics. Preserve the configured fallback while investigating instead of presenting stdio and remote OAuth as interchangeable fixes for every failure.

Remote 401

Authorization missing, invalid, or expiredRepeat the documented OAuth flow or refresh path; never append a token or API key to the URL.

Remote 403

Scope or Origin validation can deny accessInspect the response and metadata before changing credentials or transports.

stdio exits

Local child-process or configuration problemInspect executable resolution, stderr, environment injection, and process working directory.

Keep transport, authentication, and processing boundaries separate

Remote OAuth changes how a client reaches and authorizes the MCP server. OfflineCreator's live protected-resource metadata names the MCP resource, points clients to its authorization server, advertises models, read, and generate scopes, and specifies bearer tokens in headers. Its authorization metadata advertises authorization-code and refresh-token grants plus S256 PKCE. These live documents establish advertised capabilities, not proof that every MCP client completes the flow correctly.

Local stdio changes process placement, not the generation backend. The @offlinecreator/mcp README says the subprocess calls the Studio API and that Studio generations run on disclosed cloud providers. In package 0.1.2, OFFLINECREATOR_API_BASE is limited to the trusted OfflineCreator origin or localhost; the former OFFLINECREATOR_ALLOW_INSECURE_API_BASE override from 0.1.1 is not active. Operators should therefore evaluate the local package, its environment, and the remote Studio account as separate trust boundaries.

Remote boundary

Client, OAuth server, MCP endpoint, Studio accountConsent and bearer authorization replace a copied personal API key in the documented remote configuration.

stdio boundary

Client process, local package, environment secret, Studio APIThe key and upload root require local secret and filesystem controls.

Evidence limit

Metadata and documentation verifiedNo fresh client-by-client consent, refresh, revocation, or generation acceptance run was completed for this page.

Choose the transport by where setup and files live

Choose remote OAuth when the MCP client supports a remote HTTP server and you want browser consent instead of placing a Studio API key in the client file. Choose local stdio when the client can launch a subprocess and the workflow must pass an approved local image path through the published package. Both choices are MCP transports for the same cloud Studio service; local stdio does not make image or video generation run on-device.

The protocol distinction is operational rather than a different tool language. The current MCP specification says protocol semantics are identical across transports. stdio exchanges newline-delimited JSON-RPC with a client-launched subprocess, while Streamable HTTP sends each message as an HTTP POST and can return either JSON or a request-scoped SSE stream. OfflineCreator documents its hosted endpoint as Streamable HTTP with OAuth and its package as the local stdio fallback.

Credential setup

Browser OAuth remotely; scoped API key for stdioThe remote URL-only example stores no API key in the configuration. The stdio example supplies OFFLINECREATOR_API_KEY through secret configuration.

Runtime ownership

Hosted endpoint versus client-launched packageRemote operation depends on network HTTP; stdio depends on Node, npx or an installed package, and child-process lifecycle.

Local image path

Documented for the stdio packageupload_input paths are jailed beneath OFFLINECREATOR_UPLOAD_ROOT, which defaults to the process working directory.

Generation location

Cloud Studio for both choicesTransport location does not change the disclosed cloud-provider processing boundary.

Match the choice to the operator

Remote OAuth is the better documented default for a supported client when the operator wants a short URL configuration, browser consent, and the ability to revoke the OAuth connection from account Settings without copying a personal key into the file. Local stdio is the documented fallback when a client lacks the required remote setup or when a controlled local image path must be passed through upload_input. It requires ownership of the package runtime, environment secret, upload root, upgrades, and subprocess diagnostics.

Use neither label as a privacy shortcut. Remote OAuth avoids a copied API key in the documented configuration, but it still authorizes a cloud MCP endpoint. Local stdio keeps the MCP subprocess local, but the package still sends Studio API requests and generation still uses disclosed cloud providers. If the requirement is on-device generation with no cloud processing, this comparison does not satisfy it.

Continue with the narrow setup or authentication decision

Use the remote setup page when the chosen client supports the hosted OAuth endpoint. Use the stdio setup page when you need package installation, scoped-key configuration, or a jailed upload root. If the unresolved question is OAuth versus API-key risk rather than transport mechanics, continue to that dedicated comparison.

Editorial boundary

This page owns the remote OAuth versus local stdio transport decision for OfflineCreator. It does not own client-specific configuration syntax, a general OAuth-versus-key comparison, fully offline generation, or claims that every client supports both options. Refresh product documentation, live OAuth metadata, and the current MCP transport revision before changing the verdict.