The hosted endpoint at https://mcp.socialrouter.io/mcp takes a bearer token on every request. It forwards whatever token your client sends to the API, which resolves it to your account and bills what you run. There are two ways to get that token. Signing in is the shorter path: your client finds out where to log you in, opens a browser, and stores the token itself, so you never see a credential. An API key works everywhere, including clients that cannot open a browser, servers, and shared configuration. It is the same sr_live_… key the API uses.

​
Signing in

Add the server with no credential at all, and let the client do the rest:
The first time it connects, the client asks you to authenticate and opens socialrouter.io in your browser. You approve the connection, and from then on it holds a token and reconnects on its own.
You still need a SocialRouter account, and the same credits apply. Signing in changes how the client proves who you are, not what you pay for.

​
What happens under the hood

1

The client asks who can log you in

Its first request has no token, so the endpoint answers 401 with a pointer to /.well-known/oauth-protected-resource/mcp. That document names the authorization server.
2

It registers itself

Clients register dynamically, which is why there is nothing to set up on your side and no client ID to copy.
3

You approve it

The browser lands on the consent screen at socialrouter.io/oauth/consent, which names the app asking for access. Approving is what creates the connection.
4

It gets a token bound to this endpoint

The token carries https://mcp.socialrouter.io/mcp as its audience, and the API rejects it anywhere else. A token that leaks cannot be replayed against the rest of your account.

​
Managing connected apps

Every app you approve gets its own line in the dashboard, next to your API keys, named after the client that registered. Claude Code shows up as Claude Code (OAuth), for instance. Those lines have no key to copy, because none exists: the token is what authenticates, and the line only records who spent what. Usage is attributed per connected app, exactly as it is per key, and credit limits work the same way. Removing a line revokes that app’s ability to spend, and reconnecting from the client starts a fresh approval. Approving the same client twice reuses one line, so reconnecting after a laptop wipe does not scatter your usage across duplicates.

​
API keys

Nothing about keys changed. Send one as a bearer token and the client never runs a login at all:
Create keys in the dashboard. Each is shown once, at creation. Reach for a key when:
  • your client has no OAuth support, or you would rather not have it open a browser;
  • the config is shared with a team, and each teammate supplies their own key through an environment variable;
  • the server runs unattended, in CI or a container, where nobody is there to approve anything.
A configured header wins. A client that has a key never sees the 401 that starts a login, so if you set a header and want to sign in instead, remove the header first.

​
Which clients can sign in

​
If something goes wrong

It is looking for the metadata document. Check that it answers:
You should get a JSON document naming resource and authorization_servers. If you get a JSON-RPC error instead, the client is asking an older version of the endpoint. Remove the server and add it again.
The connection was revoked, or the token expired and could not be refreshed. Reconnect from the client to approve it again. If you disconnected the app in the dashboard on purpose, that is the expected result.
Both forms are bearer tokens, so the same call tests either one:
A 401 means the credential is wrong, revoked or missing. A response containing "serverInfo" means the endpoint is fine and the problem is in your client config.

​
Next steps

Connect your client

The guide for the app you actually use.

Tools reference

What list_services, run, get_extraction and get_account do.