Connectors

Connectors let an agent act through software accounts a member or an organization already owns. CoreSpeed stores the credential, refreshes it when the provider allows, and exposes the connector's operations as namespaced MCP tools — notion__create_page, slack__post_message — on the same /mcp endpoint as everything else. The agent receives tools, never the token.

What you can connect

The registry keeps growing, and what any one caller can connect is decided per environment and per request: a connector is offered only where CoreSpeed holds credentials for it and upstream approval is complete, and the answer differs by organization. The authenticated index is the only inventory worth trusting:

curl https://api.corespeed.io/connectors \
  -H "Authorization: Bearer $CORESPEED_API_KEY"

Do not hard-code a connector list or count into a client — read this index. Withholding never orphans a live grant: an account you already hold on a connector that stopped being offered stays in the index, and its tools stay in tools/list, until you disconnect it. The full response shape is in the connector list reference.

Three ways to connect

OAuth

The default. The member clicks Connect, reviews the requested scopes on the provider's consent screen, and authorizes. CoreSpeed keeps the access and refresh tokens inside the organization boundary and refreshes them on its own. A handful of connectors use OAuth 1.0a (auth.type: "oauth1a", such as Trello and Zotero); the experience is the same. The consent screen names CoreSpeed as the requesting application because the OAuth client is CoreSpeed's.

Paste an API key

Some connectors accept a credential from your provider account instead of, or alongside, OAuth. The index says which: key-only connectors carry auth.type: "api_key" (Stripe is one), and an OAuth connector that also takes a key carries auth.api_key_connect: true. In the dashboard the two methods appear side by side.

A pasted key is stored encrypted as a connection — one row, with the same private-or-shared visibility as any OAuth account. Some vendors let CoreSpeed verify the key at paste time; where they do not, the connection is stored unverified and the index marks it (api_key_probe: false, key_verified: false). Rotation is a reconnect: paste the new key and the connection updates in place. Disconnecting deletes CoreSpeed's copy and nothing more — the key itself keeps working until you revoke it in the vendor's dashboard.

A rejected call does not change the connection's status. A vendor 401 flips a key connection to needs_reauth only when the vendor names the credential itself with a standard code — invalid_token, invalid_client, or invalid_grant — rather than CoreSpeed guessing from a failed request.

Bring your own OAuth app

Where CoreSpeed opens the mechanism for a connector, an organization admin can register the workspace's own vendor OAuth app: paste its client_id and client_secret, and every new connection in that workspace authorizes through that app. This is the route for vendors whose review process gates a shared app — Google, Microsoft, and Meta among them — since your own app needs no review from CoreSpeed.

The index tells you where you stand: credential_source.active is "platform" (CoreSpeed's app), "org" (yours), or "none" (the mechanism is open but nothing is configured, so members see a setup prompt until an admin finishes it). The setup dialog lists the connector's required scopes and the redirect URI to register with the vendor; if your app grants fewer scopes than the connector's tools need, the connect fails with the exact difference and stores nothing.

Lifecycle is deliberately blunt. Rotating the secret under the same client_id disturbs nothing. Replacing the client_id, or deleting the app, moves every connection issued through it to needs_reauth, and members reconnect through the new source; the confirmation states how many. Calls made through your own app are not metered by CoreSpeed — holds and the activity trail still apply.

Private and shared accounts

Every connection is private — usable only by the member who connected it and that member's clients — or shared with the whole organization. Any member can connect either kind. An agent principal reaches shared accounts only, never a member's private ones.

Removal follows the same shape: a private account is removed by its member; a shared one by whoever connected it or an org admin. The index reports both rules per account as can_remove, so a client does not have to guess.

One connector can hold several accounts — two Slack workspaces, a personal and a company X handle. Each account has an alias, shown in the index and renamable with manage__accounts_rename. Connector tools accept an optional account argument naming the alias; when more than one account is in scope and the argument is omitted, the call returns an isError result listing the aliases to choose from. No provider account id or token ever needs to appear in a prompt.

Connection lifecycle

1. The member opens Dashboard → Connectors, picks a connector, and chooses a method and a visibility.
2. CoreSpeed stores the grant or key inside the organization boundary and, for OAuth, refreshes it when the provider permits.
3. The connector's namespaced tools appear in tools/list on the existing /mcp endpoint — no second MCP server to add.
4. Every agent using the same CoreSpeed identity can use the connection; no provider credential is copied anywhere.

Reauthorization

needs_reauth is a recoverable state. The connector stays known and its tools stay visible; calls fail until the account is reauthorized. It is reached when a refresh fails, when a vendor names the credential as invalid, or when an organization's own OAuth app is replaced or deleted. Send the user to Dashboard → Connectors to reconnect — do not rotate the CoreSpeed key or rewrite client configuration, neither of which is broken.

Connectors are their own switch

Built-in capabilities have organization and member visibility controls. Connectors do not: connecting and disconnecting the account is the connector's enable and disable. See Capability controls for the built-ins.

Your own MCP servers

An organization admin can also register any HTTPS MCP server as a remote connector; its tools join the same surface as org__<slug>__<tool>. See Remote MCP servers.