Connectors

Connectors are curated external services you connect to a workspace with point-and-click sign-in — Linear, Stripe, Gmail, Outlook, Notion, and more. Once connected, the service’s tools are available to the agent for everyone in that workspace.

A connector is the only kind of thing a workspace installs: every one is a remote MCP server the platform connects to. This page covers connecting one that a workspace shares.

Connecting a service to yourself instead?

This page is about connectors shared by a workspace. To connect a service to your own identity — so it follows you across workspaces and you grant it into each one — see Personal connectors.

Where connectors live

Connectors are managed per workspace, under Settings → Connectors for the workspace you’re viewing. The page lists what’s already connected; the Browse button opens the full directory of available services. Browse lists what the workspace already has too, in an Installed section below the rest, each with a link to its Configure page.

A connected service is shared by everyone in the workspace — its tools are available to all members. The credentials behind it are stored once, in the workspace.

Connecting a service

1. Open Settings → Connectors for your workspace and click Browse.
2. Find the service you want. Each card shows its name and a short description; search filters by name, description, or tag.
3. Click Install. For a service with a sign-in, you’re redirected to the vendor’s sign-in page. A provider or smithery connector has none: the card reads Installed and you stay on Browse. If it installed but failed to start, you’re taken to its Configure page instead, where the reason is shown.
4. Sign in and approve the requested access. You’re returned to NimbleBrain, and the connector’s row updates to Connected once the handshake settles.

Installing or connecting a service requires the admin role in the workspace.

On a connector’s Configure page, the header shows the connector’s name and status (“Connected as …” when there is a sign-in), and its ⋯ menu holds Documentation, Disconnect, Uninstall and the connector’s version and tool count. Under the header come its connection settings, then the connector’s own Settings section when it has one, then Tool permissions, collapsed to a summary until you choose Show tools.

Disconnect appears only for a connection someone signed in to: the dcr and static kinds, and a brokered connector whose broker can reconnect it, such as an OAuth composio toolkit. Disconnecting is reversible — reconnecting re-runs that sign-in. A provider connector (one of the platform’s own services) or one with a stored credential has no sign-in, so there is nothing to disconnect and the menu does not offer it; remove it with Uninstall.

Disconnect is shared: it disconnects the connector for everyone in the workspace, and asks you to confirm first. The connector stays installed with its tool permissions and settings, and reads Not connected with a Connect action — a resting state, not an error. To remove it entirely, use Uninstall. A connection that stops working without anyone disconnecting it (the vendor revoked or expired its access) reads Reconnect in amber instead, because someone needs to act on it. provider and smithery connectors have no interactive sign-in: their credential is held by the platform or the broker, so they reconnect without prompting you.

The auth kinds

Every connector declares how it authenticates. As a user you rarely need to care — the Install / Connect button does the right thing — but it explains what each one asks of you, and who had to set it up first.

Kind	What it means	What you do	Who sets it up
dcr	Dynamic Client Registration. The platform registers an OAuth client with the vendor on the fly.	Click Install, sign in.	None
static	The vendor requires a pre-registered OAuth app.	An admin clicks Set up once; after that everyone connects with Install.	Workspace admin, per workspace
composio	Brokered through Composio, a managed-connector provider.	Click Install. OAuth toolkits send you through the vendor’s sign-in; API-key toolkits open a short form for the service’s API key.	Operator, platform-wide
smithery	Brokered through Smithery, a managed-connector provider that also hosts the MCP session.	Click Install. A server needing no account connects immediately; one needing sign-in or configuration reports that on the install attempt, with a link to a Smithery-hosted setup page to complete first.	Operator, platform-wide
provider	A connector whose credential is supplied server-side by a named credential provider — no vendor sign-in, no operator OAuth app, no per-user secret. Covers both the platform’s own connectors, whose credential the runtime mints against the fleet authorizer, and a hosted gateway you hold one account key for.	Click Install. Usually there is nothing to enter; an entry marked Needs a credential asks for one first (see below).	Operator — the catalog entry, plus the fleet-authorizer environment or the gateway’s declared key

For a static connector that hasn’t been set up yet, non-admins see “Operator setup required” until an admin completes the one-time Set up step.

Connectors that need a credential only you hold

Some services read something the platform cannot supply for you — your own database, your own account key. Their Browse card is marked Needs a credential, and Install opens a short form before adding anything.

Fill it in and the connector is stored, installed, and connected in one step. Cancel and nothing is installed, which is the right outcome: the connector could not have reached anything.

Values are masked, go straight to the workspace credential store, and are never shown again — not in the UI, not in a log, and never in a conversation. Replace one later from the connector’s Configure page; the next request uses it, with no restart. See Secrets for the storage model.

Uninstalling takes them with it. The confirmation names each stored credential the connector owns before removing it — and reinstalling asks for the values again, so there is nothing to hold back. See Uninstalling.

The last three rows depend on something configured once for the whole platform rather than anything in this workspace — but on different platform machinery: composio and smithery on a configured connector provider, provider on the fleet authorizer or a declared gateway. None of them is something a workspace admin can turn on.

Where your secrets live

Tokens and credentials for a connector are stored in the workspace, at workspaces/<wsId>/credentials/ on the platform — never echoed back to the UI. For static-auth connectors, the admin-configured OAuth client ID is recorded on the workspace; the client secret goes into the same credential store and is never returned in any API response. For composio connectors, the platform-wide Composio API key lives in the platform environment, not in the workspace. For an API-key Composio toolkit, the key you paste into the connect form is sent to Composio and never stored by the platform — only an opaque account pointer is kept. smithery connectors work the same way: the platform-wide Smithery API key lives in the platform environment, and any service credential is held write-only by Smithery — the platform keeps only the connection id.

Because credentials are workspace-scoped, connecting a service in one workspace never exposes it to another. See Credentials for the full storage model.

Limiting which connectors a workspace can use

Two workspace settings gate the connector catalog:

• connectorsAllowList — when set, only the listed connector IDs appear in Browse and can be installed in that workspace. Leave it unset to allow the full catalog.
• oauthOperatorApps — records the per-workspace OAuth client configuration for static-auth connectors (the “Set up” step writes here).

See Workspace configuration for the field reference.

What installing does — and does not — do

Installing a connector records the server’s URL on the workspace and starts an authenticated connection to it. Nothing is downloaded, unpacked, or run on your platform host: the runtime holds a URL and a credential, and the server runs wherever its operator runs it. A connector that also ships UI surfaces its views through ui:// resources read over that same connection.

Delivering a notification through a connector

A connector’s tools are not only for the agent to call. A workspace admin can write a notification route that calls one on its own: when a connector reports something — a domain went active, a reply landed — the route posts it through whichever connector you use to reach people. Install a Slack, Twilio or mail connector and the route is the whole integration; there is nothing to build.

Two things follow from a route calling a tool with nobody present:

• It runs as the admin who wrote it. Every gate that applies to that person in chat applies here — workspace membership, the connector’s own permissions, the audit trail. If they leave the workspace the route stops rather than running as nobody.
• The connector has to be installed in that workspace. The route names a tool from the workspace’s own installed set, and saving one that names anything else is refused.

Usage overlays

When you install a connector, the platform can automatically apply a short usage overlay — curated guidance for that connector’s tools, surfaced into the conversation the first time the agent calls one of them (never into the system prompt). It’s always on and fail-soft; a connector with no curated overlay installs exactly as before (a missing overlay is simply a no-op). See Connector skill overlays for how it works, and use the connector tool’s list_bound_skills action to see what’s bound in a workspace.

What’s next

• Skills — connector skill overlays
• Connector Configuration — the entry a connector writes to workspace.json
• Credentials — how secrets are stored
• Workspace configuration — connectorsAllowList and oauthOperatorApps