Fix QUERY_API_KEY_FORBIDDEN in OfflineCreator MCP

Remove api_key from the URL before retrying

QUERY_API_KEY_FORBIDDEN is a deliberate rejection from OfflineCreator's legacy MCP endpoint, not a hint that the query parameter needs a different value. A public probe using a fixed non-credential marker in `https://offlinecreatorstudio.com/mcp?api_key=...` returned HTTP 401 and the machine-readable code `QUERY_API_KEY_FORBIDDEN`. Its error text said that API keys in query strings are unsupported and directed the caller to use `Authorization: Bearer`.

Delete the entire `api_key` parameter, including its value, from the configured URL. Then choose one documented authentication path: use the recommended remote OAuth endpoint, keep a fallback key in a fixed Authorization header for the legacy remote endpoint, or pass the key through `OFFLINECREATOR_API_KEY` to the local stdio package. Do not rename the query parameter or append the same secret under another URL field.

Recognize the exact rejection boundary

The verified response has three useful facts: the HTTP status is 401, the JSON `code` is `QUERY_API_KEY_FORBIDDEN`, and the JSON `error` says `API keys in query strings are not supported. Use Authorization: Bearer.` The response does not establish whether the supplied value was valid, revoked, expired, or correctly scoped because the test used a fixed invalid research marker and no credential. Diagnose the transport location first instead of treating this response as a key-validity check.

Observed request

Legacy `/mcp` URL with an `api_key` query parameterThe research probe contained no production, test-account, or user credential.

Observed response

HTTP 401 and `QUERY_API_KEY_FORBIDDEN`The body explicitly points to the Bearer Authorization header.

Not established

Key validity, scopes, or authenticated MCP behaviorThose questions require a separate credential-safe test after the URL is corrected.

Find where the unsafe URL was assembled

Inspect the MCP client's server configuration, generated launch command, environment-variable template, proxy rewrite, and any copied setup snippet. Search for the parameter name `api_key`, but do not print or copy its value. The unsafe form may be hidden in a URL assembled from separate host and query fields, so confirm the final sanitized hostname, path, and parameter names shown by the client's diagnostics.

If the failing address is `https://offlinecreatorstudio.com/mcp`, it is the documented legacy API-key fallback. If the intended setup is remote OAuth, the current OfflineCreator connection page and published package metadata identify `https://mcp.offlinecreatorstudio.com/mcp` as the recommended endpoint and show it as a URL-only client entry. Switching endpoints is appropriate only when the client supports remote MCP authorization; it is not a reason to copy a key into the OAuth URL.

Put the credential in the documented channel

For remote OAuth, configure only `https://mcp.offlinecreatorstudio.com/mcp`, reconnect the server, and complete the Studio browser sign-in presented by the client. OfflineCreator describes this as the recommended remote connection and says no API key is stored in the client configuration file. Do not add an Authorization header containing a personal key to that OAuth example.

For local stdio, the current published `@offlinecreator/mcp` package reads the fallback key from `OFFLINECREATOR_API_KEY`. For the legacy remote endpoint, the verified query-parameter rejection directs callers to use `Authorization: Bearer`. Environment interpolation and secret-header syntax differ among MCP clients, so use the current client-specific guide rather than assuming one placeholder format works everywhere.

The current MCP authorization specification also requires access tokens to be sent in the Authorization header on every HTTP request and says clients must not include access tokens in URI query strings. That transport rule supports the same correction even when the credential is an OAuth access token rather than an OfflineCreator personal API key.

Rotate a key that may have appeared in a URL

Correcting the configuration stops future URL exposure, but it does not invalidate copies already retained elsewhere. OAuth security guidance identifies browser history as one way a query-string token can be exposed. URLs may also be copied into tickets, screenshots, shell history, proxy records, analytics, or referrer data depending on the surrounding tools. Treat those locations as possible exposure paths, not proof that a leak definitely occurred.

If a real key appeared in the failing URL, revoke it in Studio Settings, create a replacement with only the scopes the task needs, update the approved secret location, and reconnect. OfflineCreator's current public guidance says to revoke a fallback API key immediately if it may have leaked. Do not paste the old or replacement value into chat, a support request, a source file, or a diagnostic command.

Continue from the next failing boundary

Return to the troubleshooting directory if removing the query parameter reveals a different status. Use the 401 guide when the corrected remote OAuth endpoint produces a Bearer challenge or rejects a token. Use the OAuth discovery guide when the client never follows protected-resource metadata or never opens browser authorization. These guides diagnose later boundaries; they should not be used to justify leaving a secret in the URL.

Evidence boundary

This draft is grounded in a credential-free live check of the public legacy endpoint, OfflineCreator's current connection page, the current npm registry package record and README, the current MCP authorization specification, and OAuth security guidance. The latest last30days run returned 49 items, but none documented OfflineCreator's QUERY_API_KEY_FORBIDDEN behavior. Instagram failed with HTTP 404, Reddit was partial after HTTP 429, X was not configured, and Polymarket had no exported telemetry lane. The returned GitHub, web, Hacker News, Reddit, TikTok, and YouTube material was adjacent, promotional, stale, or off-topic. No community anecdote or workaround was relevant enough to support a page claim.

No authenticated request was made, no key or token was inspected, and no claim is made here about a particular client's secret interpolation, token cache, user-interface labels, or successful authenticated result. Those details remain client- and version-specific and should be verified through the reader's current first-party client documentation.