API keys and OAuth

Two different things need credentials: the AI client calling your MCP server, and your API, which SourceMCP calls on the client's behalf. They never mix: what a client sends to SourceMCP is never forwarded to your API.

API keys

An API key (mcpk_live_…) belongs to one server. Create keys on the server's API keys tab, up to 10 active at a time. A key is shown once, when it's created; SourceMCP keeps only a hash, so a lost key can't be recovered: revoke it and create another.

Clients send it as Authorization: Bearer mcpk_live_…. Keys in query strings are refused.

Use API keys for clients configured from a file (Cursor, VS Code, Claude Code, mcp-remote), for shared machines, and anywhere you want to revoke one client's access without affecting the others.

OAuth

With OAuth, the client opens a browser window, you sign in with your SourceMCP account and approve access, and the client gets a short-lived token for that one MCP URL. Only the account that owns a server can connect to it this way.

Use OAuth where there's no header field (Claude's custom connectors, ChatGPT), or when you'd rather not handle keys at all.

Credentials for your API

SourceMCP calls your API with credentials you give it per server. They are encrypted at rest, used only for calls to that server's base URL, and write-only: after saving, the dashboard shows only header names and a masked hint, and no API returns them.

• Headers: up to 10, such as Authorization: Bearer … or X-API-Key: ….
• Query parameters: up to 10, for APIs that read a key from the URL.

Upstream sign-in

Some APIs have no static key, only a login endpoint that returns an access token (often with a refresh token). SourceMCP finds that endpoint in the spec and offers Sign in to the API:

1. Check the detected login (and refresh) endpoint, and which response fields hold the tokens. If the API sets the tokens as cookies instead, choose Cookie and type the cookie names.
2. Sign in once with the API's username and password. They are used for that one request and dropped; SourceMCP never stores them.
3. SourceMCP keeps only the returned tokens, encrypted, and attaches the access token to every call.

With a refresh token, SourceMCP renews the session before it expires. Without one, the server stops working when the access token expires, and the dashboard asks you to Sign in again. Endpoints that need no authentication, such as a health check, keep working either way.