Authentication

Bearer token, custom header, OAuth or none, what sremcp sends for each, and how secrets are kept.

Choose the Authentication that your server expects:

OptionWhat sremcp sends on every requestTypical servers
Bearer tokenAuthorization: Bearer <Secret>Grafana (MCP_GRAFANA_SERVER_TOKEN), Supergateway (--apiKey), GitHub with a personal access token
Custom header<Header name>: <Secret>X-API-Key, or Authorization with a full value such as Sentry-Bearer …
OAuth (sign in with the server)Authorization: Bearer <access token>, from a sign-in you do onceGitHub, Sentry, servers behind Clerk or other OAuth providers
NoneNothingServers that need no credentials, or are protected by the network only

Bearer token

Enter the token as the Secret, without the word Bearer. sremcp adds it.

Custom header

Enter the Header name (letters, digits and dashes, for example X-API-Key) and the full header value as the Secret. To send an Authorization header with a scheme other than Bearer, use Header name Authorization and put the whole value in Secret, for example Sentry-Bearer sntryu_….

OAuth

For servers that implement the MCP authorization spec: you click Connect, sign in on the provider's page, and sremcp keeps and refreshes the tokens. It's the only option where the agent acts as a person's account rather than a shared key. See OAuth sign-in.

None

sremcp sends no credentials. Use it only for servers that are meant to be public, or that only your network can reach (on a self-hosted sremcp).

How secrets are kept

  • Secrets are encrypted with AES-256-GCM, using a key derived for your organization and bound to the server. A secret copied to another server or organization won't decrypt.
  • Nobody can read a secret back, in the console or the API. Rotate secret replaces it.
  • Secrets go only to the server they belong to. They're never sent to the AI model, and never to another server.
  • Use a read-only credential. The integration guides show how to create one for each server.

On this page