Servers that need their own sign-in
Connect MCP servers that use an API key or OAuth, including servers where each member signs in with their own account.
Many MCP servers need a credential of their own: an API key, or an OAuth sign-in with the service behind them. CoreValue holds that credential and adds it to each request it forwards. Your MCP clients never see it, and the CoreValue key or sign-in a client uses is never forwarded to the server.
This page is about how the gateway signs in to a server. How your clients sign in to the gateway is a separate setting, described in Connect MCP clients.
Choose how the server authenticates
When you add or edit a server on Gateway › MCP servers, the Authentication field has four choices:
| Choice | What it does | Use it when |
|---|---|---|
| None | The server needs no sign-in. | The server is open, or reachable only from where you run it. |
| Header / API key | One secret you paste, sent in a header. Every member uses it. | The server takes a static API key or token. |
| OAuth — service account | CoreValue signs in as one app identity and refreshes its token. Every member uses it. | The server supports machine-to-machine OAuth, and every caller should act as the same identity there. |
| OAuth — each member signs in | Each member connects their own account the first time they use the server. Calls act as that member upstream. | Calls must act as the person making them, with their own permissions at the service — a code host, an issue tracker. |
With Header / API key, the secret is sent as
Authorization: Bearer <secret> unless you name another header and prefix.
It is stored encrypted and never shown again.
With OAuth — each member signs in, only members who connect their MCP client by signing in can use the server, because only a sign-in tells CoreValue which member is calling. A client that connects with an API key does not see the server's tools, and a call to it is refused with a message saying to connect with CoreValue sign-in. Turn on Client sign-in first; the dialog warns you when it is off.
Add an OAuth server
Owners and admins add servers. Each server needs a Server ID: 1 to 64
lowercase letters, digits or hyphens. It is used in tool names
(<server-id>__<tool>) and in the server's URL, and cannot be changed later.
Enter the server and choose OAuth
Go to Gateway › MCP servers and click Add server. Enter the Server ID, a Name and the server's URL, then choose OAuth — service account or OAuth — each member signs in under Authentication.
Find the sign-in settings
Click Find sign-in settings. CoreValue asks the server where its members sign in and how CoreValue can register with it, and shows what it found under Sign-in settings found:
- Members sign in at (or, for a service account, CoreValue signs in at): the authorization server's host.
- Client registration: how CoreValue identifies itself there.
- Automatic: CoreValue identifies itself with its client metadata document, or registers itself with the server. Nothing more to do.
- This provider offers no automatic registration: you register CoreValue with the provider yourself, and enter the client ID and secret it gives you. See the GitHub example below.
- Disconnecting: whether CoreValue can revoke access at the provider when a member disconnects.
- Scopes: what the server asks for. Space-separated; leave them as found to use what the server asks for.
If the server does not say where its members sign in, the dialog asks for
the Authorization server (issuer): the provider's issuer URL, for example
https://auth.example.com. Enter it and look again.
You cannot save an OAuth server until its sign-in settings have been found for the URL and choice you are saving.
Enter your own client, if needed
Tick Use a client I registered with the provider to use a client you registered yourself, even where automatic registration is offered. It is ticked for you when the provider offers none. Enter the Client ID and Client secret. The secret is stored encrypted and never shown again; when you edit the server later, leave it empty to keep it.
A service account always needs a client secret.
Save, then test
Click Add server, then Test on the server's row. What Test does depends on the choice:
- OAuth — each member signs in: Test uses your own connection to the server. If you have not connected yet, it says Each member signs in to this server. Connect your account to test it., and sends nothing. Connect from Connected accounts (below), then test again. If the server rejects your connection, Test says so and asks you to reconnect.
- OAuth — service account: Test uses the service account's token, and says so if the server rejects it.
- Header / API key and None: Test sends the stored credential, if any.
Example: GitHub's MCP server
GitHub's MCP server is at https://api.githubcopilot.com/mcp/. GitHub offers
no automatic client registration, so you register CoreValue with GitHub first:
-
In GitHub, create an OAuth app (under your organisation's or your account's developer settings). Set its Authorization callback URL to:
https://api.corevalue.dev/v1/public/mcp/upstream/callback -
Copy the app's client ID, and generate a client secret.
-
In CoreValue, add the server with a Server ID such as
github, the URL above, and OAuth — each member signs in. -
Click Find sign-in settings. The dialog reports that the provider offers no automatic registration, and that GitHub offers no revocation.
-
Enter the GitHub app's Client ID and Client secret, check the Scopes, and click Add server.
Each member then connects their own GitHub account, and their tool calls act as them on GitHub.
Use the same callback URL for any other provider where you register CoreValue yourself.
Connect your account
On a server where each member signs in, every member connects their own account once. There are three ways to do it, and all end on the same pages.
From Connected accounts. Gateway › MCP servers › Connected accounts lists, under Servers you can connect, the servers you have not connected yet. Click Connect.
From the MCP client. Until you connect, a client on
https://gateway.corevalue.dev/mcp sees one tool from the server,
<server-id>__connect (Connect your server account to use its tools.).
Calling it, or any of the server's tools, returns a connect link. A client on
https://gateway.corevalue.dev/mcp/<server-id> has its requests refused, with
the connect link in the error message. Open the link in your browser.
When you add the client. A client added at
https://gateway.corevalue.dev/mcp/<server-id> that signs in to CoreValue
also signs you in to the server in the same step: the consent screen says
You will also sign in at the provider's host. If that sign-in fails or you
cancel it, the client is still connected to CoreValue, and you connect the
server later from a link.
The connect page, Connect server as your email, names the host you will sign in at. Click Continue, sign in there and grant access. CoreValue stores the access it grants, encrypted, and uses it only for your calls to that server. When the page says the server is connected, return to your MCP client and try again.
A connect link works once, for ten minutes, and only for the CoreValue account it was made for. If it has expired or was already used, ask your MCP client for a new one or reconnect from Connected accounts. If you are signed in as someone else, the page says the link belongs to another account.
Connected accounts
Gateway › MCP servers › Connected accounts shows, under Your accounts, each server you have connected: where you signed in, the scopes granted, when you connected and last used it, and its Status.
- Needs reconnecting means the provider stopped accepting the connection — for example, you removed CoreValue's access there. Click Reconnect to sign in again. CoreValue renews access in the background otherwise, so you do not reconnect when a token expires.
- Disconnect stops your calls to that server at once. Where the provider supports it, CoreValue also asks the provider to revoke its access. Where it does not — GitHub is one — the dialog says so: also remove CoreValue's access in your account settings at the provider. On GitHub, that is the OAuth app in your authorized applications.
Owners and admins also see All connected accounts in organisation, with each member's server connections, and can disconnect any of them.
When connections end on their own
- The server changes. Changing a server's URL, authorization server, client or authentication choice ends every member's connection to it, because their access was granted for the old settings. The dialog warns you before you save. Members connect again the next time they use the server. Changing only the scopes, the name or the allowed tools keeps connections.
- The server is removed. Its connections end with it.
- A member leaves the organisation. Their connections can no longer be used.
Related
- Connect MCP clients: API keys, client sign-in and Connected clients.
- Add MCP servers
- Tool-call logging and cost