Set up the recommended remote OAuth MCP connection

Use remote OAuth only when the client supports HTTP authorization

Start with the client, not with a copied JSON shape. The current Model Context Protocol authorization specification defines OAuth for HTTP-based transports and says stdio implementations should obtain credentials from the environment instead. A client that supports remote Streamable HTTP and MCP authorization can use this path; a stdio-only client needs the separate local setup.

For OfflineCreator, the recommended resource URL is https://mcp.offlinecreatorstudio.com/mcp. Add that exact URL using the current official instructions for the target client. OfflineCreator's first-party setup page says its published remote OAuth configuration stores no API key in the file and keeps stdio and legacy API-key remote access as fallbacks.

Choose remote OAuth

HTTP-capable MCP clientConfirm support from the installed client's current official documentation before configuring the resource URL.

Choose another path

stdio-only or OAuth-incompatible clientFollow the local stdio guide instead of adding OAuth fields the client does not understand.

Let discovery drive the browser authorization sequence

After the client contacts the protected MCP resource without a token, it should process the 401 challenge or probe the protected-resource well-known locations. The current MCP specification requires clients to support both mechanisms. The returned resource document identifies the authorization server; the client then retrieves authorization-server metadata to learn the authorization, token, registration, and other supported endpoints.

Do not manually copy an authorization or token URL from a forum post. The client must validate that the discovered metadata issuer exactly matches the issuer used to construct the well-known request. Once discovery and client registration succeed, the client opens a browser for the resource owner's consent, receives an authorization code at its registered callback, and exchanges that code for tokens.

This division matters operationally: the MCP client owns discovery, redirect handling, PKCE state, and token storage. The person connecting the account owns the browser consent decision. If the client exposes none of those OAuth behaviors, a bare server URL cannot make it compatible.

Resource

https://mcp.offlinecreatorstudio.com/mcpThe protected MCP endpoint configured in the client.

Authorization server

Discovered from protected-resource metadataDo not substitute an unverified endpoint.

Consent

Completed by the account owner in a browserThe client resumes only after its registered callback receives the result.

Keep the client configuration deliberately small

This research verifies the HTTPS resource URL, but it does not verify a universal configuration object, file location, transport label, or connection control across MCP clients. Use the installed client's current official documentation to determine whether it supports remote HTTP authorization and where its server URL belongs. Do not transfer syntax from an unrelated client into this generic setup.

OfflineCreator's public setup page describes remote OAuth as the recommended connection and says no API key is stored in its published remote configuration. Its live protected-resource metadata says bearer tokens are presented in the HTTP header. That metadata does not specify where a particular client stores tokens or other OAuth state, so this page makes no credential-storage claim.

Local server name

offlinecreatorThe identifier used in OfflineCreator's published example; confirm naming rules in the target client's official documentation.

Remote URL

https://mcp.offlinecreatorstudio.com/mcpPreserve HTTPS, hostname, and the /mcp path exactly.

Published OAuth example

No API key in the fileThis is an OfflineCreator product statement, not a claim about every client's credential storage.

Review scopes before approving consent

OfflineCreator's live protected-resource metadata advertises three scope identifiers: models, read, and generate. The metadata names those strings but does not define their precise permissions, tool mappings, or data boundaries. This page therefore lists them without assigning operational meanings or claiming that every connection receives all three.

The MCP specification tells clients to prefer scopes named in the current 401 challenge and otherwise use the protected-resource metadata, with least privilege as the goal. Review the actual consent text presented by the authorization server. If the requested access is unclear or does not fit the intended task, cancel rather than inferring permission semantics from a short scope name.

models

Advertised scope identifierNo permission or tool meaning is assigned by this page.

read

Advertised scope identifierNo permission or tool meaning is assigned by this page.

generate

Advertised scope identifierNo permission or tool meaning is assigned by this page.

Require PKCE S256 instead of handling authorization codes yourself

A conforming MCP OAuth client must create a fresh PKCE verifier and derived challenge for the authorization request, retain the verifier locally, and send it when exchanging the returned code. RFC 7636 explains that this binds the code exchange to the initiating client and mitigates authorization-code interception. The current MCP security requirements direct capable clients to use S256 and refuse authorization when server metadata does not advertise PKCE support.

OfflineCreator's live authorization-server metadata currently advertises code_challenge_methods_supported as S256, response type code, and authorization-code plus refresh-token grants. This verifies the server-side metadata contract, but it does not prove that an arbitrary MCP client implements the flow correctly. If the client asks you to copy a returned code, token, or verifier into chat, stop and use its documented OAuth control instead.

Diagnose discovery and consent without assuming client controls

If no browser flow begins, verify the exact resource URL and use the target client's official documentation to confirm that its installed version supports remote HTTP MCP authorization. The protocol-level sequence includes a 401 challenge or protected-resource well-known lookup followed by authorization-server metadata discovery. Whether a client exposes logs or diagnostic controls for those steps is client-dependent and is not established by this research.

If a browser flow begins but the connection is not established, preserve the exact client-visible error and consult that client's official OAuth troubleshooting guidance. Do not assign a cause without diagnostic evidence from that client.

The live server metadata advertises discovery endpoints, S256, a refresh-token grant, and a revocation endpoint. Those records establish server-advertised capabilities only; they do not establish that any unnamed client completes discovery, stores or refreshes tokens, exposes tools, or supports a cache reset.

Evidence and publication boundary

No community claim is used in this page. Community coverage remains insufficient, so the draft does not infer compatibility, reliability, adoption, security outcomes, or customer outcomes from recent discussion.

This draft is grounded in the current MCP authorization specification, OAuth standards, OfflineCreator's public setup page, and live metadata. It verifies the documented server contract only. It does not claim that every MCP client supports remote OAuth, that any particular client completed browser consent, or that refresh and revocation were exercised end to end. Keep the page unreviewed until dated client acceptance evidence exists.