Connectors

Connectors let an agent act through app 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 where it is open to your organization and has a connect method — CoreSpeed's app, an app your organization may bring, or a pasted key. Where your organization may bring its own app but none is set up yet, the connector is still listed. In its Connect dialog an admin can set up that app, and a member is asked to have a workspace admin do it. A connector you already hold a connection to stays listed whatever else changes, so you can always disconnect it. The answer differs by organization, and 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

Every method ends the same way: a stored connection whose tools appear in tools/list for every agent using the same CoreSpeed identity.

OAuth

The default. The member opens Dashboard → Connectors, 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. Where the vendor does not say which account a key belongs to, the connection is named after the key's fingerprint, so a new key adds a new connection; disconnect the old one. 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 organization's own vendor OAuth app: paste its client_id and client_secret, and every new connection in that organization 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 by the member who connected it, that member's clients, and anyone the member shares it with — or shared with the whole organization. Any member can connect either kind. An agent principal reaches shared accounts and accounts shared with it, never a member's other private accounts.

The owner of a private account can share it with one member, one agent, or everyone in the organization. Choose Share on the account to open the Sharing dialog, or call manage__accounts_share from a signed-in session; an API key cannot share. A share allows every tool or a list you pick. A call to a tool outside the list fails with tool_not_granted. The owner can stop a share at any time. Slack personal accounts and connectors with an organization integration cannot be shared.

An environment narrows the other way: you pick some of the accounts you can use, each with an optional tool list, and a session at the environment's MCP URL — or a key bound to it — reaches only those. See Environments. A workspace bot (Slack's organization integration) is not an account and is in no environment.

Where the vendor can install CoreSpeed's app as its own actor, org-wide access is that organization integration rather than a shared member account: Slack's workspace bot, and Linear's app, which works under the alias corespeed-bot. Only an org admin connects one, and what is done through it is attributed to the app, not to whoever connected it. On those connectors a member's own account is private only.

Removal follows the same shape: a private account is removed by its member; a shared one by whoever connected it or an org admin. Someone a private account is shared with cannot remove it. The index reports both rules per account as can_remove, and the sharing rule as can_share, 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 with code ambiguous_account and the aliases to choose from in structuredContent.error.aliases; an alias that matches nothing answers account_not_found with the available ones. No provider account id or token ever needs to appear in a prompt.

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.

When an agent needs a connector

Connect requests are rolling out gradually; where they are not available to your organization yet, the two tools below are not listed.

An agent cannot click through a consent screen, and it should never see a key. It finds the connector with manage__connectors_search (by name or by what it needs, such as "calendar"), which also says whether it is connected already. Then it calls manage__connectors_connect with the connector id and one sentence on why it needs it. It gets back a link to that connector's page in the dashboard, which it gives to the user. The user opens it while signed in, sees who asked and why, and connects there as usual. The agent calls manage__connectors_wait, which returns once the account is usable, then reloads tools/list. The same tool covers a reconnect after needs_reauth.

The link grants nothing by itself: whoever opens it connects their own account, and the request completes only when the agent that asked can use the account. For an agent with its own key, the link goes to the agent's owner, who also shares the account with the agent on the same page and picks which tools it may use. Slack and Linear are the exception: their personal accounts are never shared, so an agent key reaches them through the organization integration instead. Inside an environment the tools answer environment_active: add the account to the environment rather than connecting a new one. Arguments and codes are in manage tools.

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.