An MCP client authenticates the connection, not each call. Sign in once through the OAuth flow your client runs, or put a key in its config — after that every tool call is authenticated for you.
Your key is on the API keys page of the dashboard. A new account has one the moment it exists — there is no provisioning step.
Connecting a client
Two ways in, and the server negotiates rather than making you choose in advance.
OAuth — the default. Connect with no credentials and the server answers 401 with a
WWW-Authenticate challenge pointing at its resource metadata. Your client runs the flow, you
approve it in a browser, and no key is ever written to a config file. That is the right choice on
a shared machine or a config you commit.
A key in the config. Send it in the x-api-key header. Simpler to automate, but the key is
then at rest on disk — put a scoped sub-key there, never your primary
key.
Either way the credential is checked against your account on every call. Rotating or revoking it takes effect immediately, even against an OAuth token issued earlier.
What a key is
A key is a UUID: a1b2c3d4-e5f6-7890-abcd-ef1234567890.
One key covers your whole account: everything your plan includes, with no per-source enablement. What the key controls is:
- Which plan applies — credits, rate limit and concurrency all come from the key's account.
- What it may reach — optionally narrowed with key scoping.
- Where it may be used from — optionally narrowed with an IP allow-list.
- How long it lives — optionally given an expiry, see key expiration.
Additional keys, each with their own name and restrictions, are sub-keys.
Keeping the key safe
Agent configs are files, and files get committed, synced and shared. What actually prevents incidents:
- Prefer OAuth. Nothing lands on disk, and the token is bound to the client that requested it.
- If it must be a config file, put a sub-key there — one per agent, revocable on its own, with its own rate limit and its own line in the usage breakdown.
- Scope it. An agent that only needs three tools should hold a key that can only reach three tools; see key scoping. An agent will call whatever it is offered.
- Never in a prompt or a system message. Anything in the context window can end up in a transcript, a log, or a model provider's retention window.
Rotating a key
Rotation replaces the key with a new one and invalidates the old one immediately. There is no grace period, so the order matters:
- Create a sub-key for the workload, or note where the current key is in use.
- Roll the new key out everywhere first.
- Rotate only once nothing is still reading the old value.
An OAuth connection survives a rotation of the underlying key. A client configured with a key in its header does not: update the config and restart it, or it will fail on the next tool call.
If a key has leaked, invert that: rotate first and accept the downtime. A leaked key is spending your credits for as long as it works.
Full procedure, including the zero-downtime pattern with overlapping sub-keys, is in key rotation.
Checking a key works
List the tools. A client that can enumerate the tool list has authenticated successfully — the list is served over the same authenticated connection the calls use. A client showing zero tools has not connected, whatever its status indicator says.
Next
With the client connected, MCP server covers transports, tool generation and the stdio bridge.
If your key needs to be narrower than your account, start at key scoping. The key itself lives on the dashboard, alongside the usage it spends.