How to register your own MCP server for your whole organization

A remote connector is an MCP server your organization registers with CoreSpeed. An org admin gives it a slug, an HTTPS URL and an auth mode. Its tools then appear on /mcp for your members with the org__ prefix, behind the same sign-in, spend caps and activity trail as every built-in capability and connector.

What do you need before you register?

Three things. You must be an org admin, or hold an sk-cs- key whose creator is one. The server must speak MCP over HTTPS. And you must decide how CoreSpeed authenticates to it. There are three modes.

Pick oauth when the server already has an authorization server and you want per-member identity upstream. Pick static_bearer for an internal service with a single service token. Pick none only for a server that is public on purpose.

How do you register the server?

1. Choose a slug. A server registered as runbooks with a tool named search appears to agents as org__runbooks__search. The org__ marker is what lets your slug coexist with a same-named built-in connector. Registration is org-scoped; no other organization sees it.
2. Choose the auth mode from the table above.
3. For oauth mode, prepare the authorization server. CoreSpeed discovers it through RFC 9728 protected-resource metadata and, when the server advertises a registration_endpoint, registers a client through RFC 7591 dynamic client registration. The client is always registered with the redirect URI below.
4. If the authorization server restricts registration, either add that redirect URI to its allowed list and keep automatic registration, or pre-register a client in its console with grant types authorization_code and refresh_token and response type code. Then pass its client_id, plus the client_secret unless it is a public PKCE-only client, with the registration.
5. Register. Use Dashboard → Connectors, the manage__remote_add tool from a signed-in client, or POST /connectors/org. The CLI has cs remote add for the same step.
6. In oauth mode, each member authorizes their own account from the dashboard. The connector's tools appear in that member's tools/list once they hold a usable grant. In static_bearer and none mode there is no per-member step.
7. Verify. manage__remote_list runs for any caller and shows the registration. A fresh session in your client shows the org__ tools in tools/list.

https://app.corespeed.io/connectors/callback

That redirect URI is fixed. The path is always /connectors/callback under the dashboard origin, so a pre-registered client only ever needs this one value. The full flow is on the remote MCP page.

What happens when an OAuth registration fails?

Two outcomes, handled differently.

If the authorization server rejects the registration with a 4xx response, nothing is left behind and the slug stays free. The error carries the HTTP status and the server's machine-readable code when it uses a registered one. Fix the configuration with one of the two setups in step 4 and register again.

If the outcome is unknown, because of a network failure, a timeout or a 5xx answer, the slug is held by a dcr_pending reservation. This stops a blind retry from creating a duplicate client on the upstream server. An org admin clears it with manage__remote_remove, passing expected_status=dcr_pending and the reservation's registration_id from manage__remote_list, then registers again.

One more detail for servers that implement registration without the optional RFC 7592 management extension. They work normally: the client registers and activates. On removal, CoreSpeed deletes everything on its side, and an inert client record stays on the authorization server, because that server offers no way to delete it.

How do calls to a remote server behave?

Like every other call on /mcp. The caller signs in once; CoreSpeed holds the upstream credential and the agent never sees it. A billing hold or a key's monthly spend cap refuses the call before it reaches your server. Each call lands in Dashboard → Activity with actor, action and outcome. If your org has Smart Approval on, writes to the remote server are judged against your policy like any other write; reads are never gated.

tools/list stays caller-specific. In oauth mode a member who has not authorized yet does not see the tools. That absence is a decision, not a bug. The connectors page explains the same rule for every connector.

FAQ

Can a non-admin register a server? No. manage__remote_add, manage__remote_refresh and manage__remote_remove need an org admin, or an API key whose creator is one. Anyone else gets admin_required. manage__remote_list runs for everyone.

Can an agent key use a remote connector? In static_bearer and none mode, yes, since the grant is org-wide. In oauth mode an agent principal has no browser to authorize with, so it has no grant of its own.

Does the server need to support dynamic client registration? No. Pre-register a client with the redirect URI above and pass its client_id and client_secret when you register.

How do I remove a remote connector? An org admin calls manage__remote_remove or removes it from Dashboard → Connectors. Members' grants on it go with it. See the authentication page for which tools need which principal.