OAuth sign-in
Connect servers that use OAuth (GitHub, Sentry, servers behind Clerk), and how sremcp identifies itself to them.
Servers built on the MCP authorization spec don't take a static key. Someone signs in once, and the server issues tokens. sremcp does that sign-in for you and keeps the tokens.
Connect
Onboard with OAuth
Choose Authentication OAuth (sign in with the server). Leave Client ID, Client secret and Scopes empty unless the provider needs a registered app (see below), then Save as draft.
Click Connect
In the Sign-in (OAuth) panel, click Connect. sremcp finds the server's sign-in page and sends you there.
Sign in and consent
Sign in on the provider's own page and approve the access it asks for. sremcp never sees your password.
You're back
The server's page says Connected. Run a connection test to discover the server's tools. The panel shows who connected, when, and the scope granted.
The agent acts as the person who connected
Every call to this server, from any role's chat or report, uses the account that clicked Connect. Connect with an account that has read-only access to what the team should see, ideally a dedicated one.
Only the person who clicked Connect can finish the sign-in, within 10 minutes. A consent link forwarded to someone else can't attach their account.
How sremcp identifies itself
The provider needs to know which app is asking. sremcp tries, in order:
- A client ID you registered. If you filled in Client ID (and Client secret), sremcp uses them.
- Its client ID document. If the provider supports
client ID metadata documents,
sremcp identifies itself as
https://app.sremcp.com/oauth/client.json. Nothing to register. Clerk and Sentry support this. - Dynamic registration. If the provider lets apps register themselves, sremcp does.
If none applies, Connect tells you to register sremcp with the provider. The panel shows which method was used, under identifies as.
Registering sremcp with a provider
When the provider needs a registered app (GitHub, for example), create one there with:
| Setting | Value |
|---|---|
| Callback / redirect URL | https://app.sremcp.com/oauth/mcp/callback (the panel shows it, with a copy button) |
| App type | Web application, with a client secret |
Then put its Client ID and Client secret on the server in sremcp. Most providers, GitHub always, refuse the sign-in without the secret.
Scopes
By default sremcp asks for the scopes the server lists, plus offline_access when the provider offers it, so the
connection can renew itself. To ask for less, set Scopes (space-separated) when you onboard the server. What was
actually granted shows as chips under scope granted.
Scopes are the provider's limit. The tools you approve are sremcp's. The agent can only call approved tools, whatever the token allows.
Keeping the connection
- sremcp refreshes the access token before it expires. The panel shows until when the current one is valid.
- If the provider refuses a refresh (the grant was revoked, or expired), the connection is cleared and the server shows The sign-in for this server expired or was revoked. An SRE or admin needs to click Connect again.
- Reconnect signs in again, for example with another account. Disconnect forgets the tokens. They stay valid at the provider until they expire or you revoke them there.