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.

Connectors are the OAuth-driven half of the Apps catalog. They share the same Browse directory; this page focuses on connecting remote services rather than installing stdio bundles.

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.

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. You’re redirected to the vendor’s sign-in page.
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 you can see who you’re connected as, Disconnect, and review or adjust which of the connector’s tools are allowed. For the kinds with a sign-in flow (dcr, static, and OAuth composio toolkits) disconnecting is reversible — reconnecting re-runs that flow. 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 platform-managed connector whose credential the runtime mints server-side — no vendor sign-in, no operator OAuth app, no per-user secret.	Click Install. There is nothing to enter.	Operator — the catalog entry and fleet-authorizer environment

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.

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. 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.

Connectors vs. stdio apps

Both install from the same Browse directory, but they differ:

• Connectors are remote services you reach over OAuth. Nothing runs on your platform host except the connection.
• Stdio apps are MCP bundles that run as a subprocess on the platform. They may declare user_config fields (API keys, settings) you fill in on their Configure page. See Installing Apps.

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

• Installing Apps — stdio bundles and the agent-driven install path
• Managing Apps — lifecycle, status, and trust scores
• Skills — connector skill overlays
• Credentials — how secrets are stored
• Workspace configuration — connectorsAllowList and oauthOperatorApps