# How to register your own MCP server for your whole organization (/blog/register-your-own-mcp-server-as-an-org-connector)

![Illustration: A simple human figure bolts a new orange door onto a long wall that already has three slate blue doors.](/blog/register-your-own-mcp-server-as-an-org-connector/hero.webp)

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.

**Register a remote connector**

1. **Choose a slug** (runbooks with tool search becomes org\_\_runbooks\_\_search) — Registration is org-scoped.
2. **Choose the auth mode** (oauth, static\_bearer or none)
3. **Prepare the authorization server** (oauth mode: RFC 9728 discovery, RFC 7591 registration) — Redirect URI: app.corespeed.io/connectors/callback. Or pre-register a client.
4. **Register** (Dashboard, manage\_\_remote\_add, POST /connectors/org, cs remote add) — Org admin only.
5. **Members authorize** (oauth mode only; each member, once, from the dashboard)
6. **Verify** (manage\_\_remote\_list; a fresh session shows org\_\_ tools)

An org admin registers it once; members see org\_\_ tools.

## What do you need before you register? \[#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.

| Mode            | What is sent upstream                                      | Who authorizes                                       |
| --------------- | ---------------------------------------------------------- | ---------------------------------------------------- |
| `oauth`         | each member's own grant, stored and refreshed by CoreSpeed | every member, once, from the dashboard               |
| `static_bearer` | one org-wide bearer token, encrypted at rest               | the admin who registers it                           |
| `none`          | no credential                                              | nobody; anyone who knows the URL can call the server |

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? \[#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`.

```text
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](/docs/connectors/remote-mcp).

## What happens when an OAuth registration fails? \[#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? \[#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](/docs/connectors) explains the same rule for every connector.

## FAQ \[#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](/docs/authentication) for which tools need which principal.