# Connectors (/docs/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 \[#what-you-can-connect] Notion, Slack, GitHub, Linear, Google Drive, Figma, Stripe, HubSpot, Salesforce, Zendesk, Discord, X — A few of the connectors on the index today. 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: ```bash 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](/docs/reference/connectors/list). ## Three ways to connect \[#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 \[#oauth] The default. The member opens [Dashboard → Connectors](https://app.corespeed.io/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 \[#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 \[#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 \[#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](/docs/authentication) 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 account of a [remote MCP server](/docs/connectors/remote-mcp) can. 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](/docs/mcp#environments-a-session-with-fewer-accounts). 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 \[#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](https://app.corespeed.io/connectors) to reconnect — do not rotate the CoreSpeed key or rewrite client configuration, neither of which is broken. ## When an agent needs a connector \[#when-an-agent-needs-a-connector] Connect links are rolling out gradually; where they are not available to your organization yet, the three 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 gets back a one-click link, which it gives to the user. The user opens it while signed in to CoreSpeed and lands straight on the vendor's consent screen; for a connector that needs a key or other input first, the link opens its page in the dashboard instead. The agent calls `manage__connectors_wait` with the same connector, which returns once it can use an account, then reloads `tools/list`. The same tool covers a reconnect after `needs_reauth`. The link works only for the person it was made for: opened by anyone else, it does nothing. It connects that person's own account, privately, and stays valid for an hour. For an agent with its own key, the link is for the agent's owner, and the account they connect through it is shared with the agent (all of its tools; narrow the share on the connector's page if you want). 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 `manage__connectors_connect` and `manage__connectors_wait` answer `environment_active`: add the account to the environment rather than connecting a new one. Arguments and codes are in [manage tools](/docs/reference/tools/manage#connect-links). ## Connectors are their own switch \[#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](/docs/capability-controls) for the built-ins. ## Your own MCP servers \[#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____`. See [Remote MCP servers](/docs/connectors/remote-mcp).