Understanding connections

Separate the installation from your access

An administrator creates the shared installation: which provider or remote server the workspace will use, how it authenticates, and which reviewed tools belong to it. Each person still needs access to that installation and, where required, their own provider authorization.

This is why an administrator can inspect an installation while a member sees Sign in required or no available tools. An enabled connection is not a blanket grant to every person. Likewise, disconnecting your personal access does not disable the installation for colleagues.

What is a connection?

A connection represents one upstream instance or workspace — a GitHub organization, a Jira project, or a Slack workspace. Each connection has its own authentication boundary, tool set, and policy scope. Separate enabled, verified production connections count separately, subject to the organization’s free connection allowance.

Connection lifecycle

A saved draft must complete provider authentication, tool review, testing, and activation. Setup readiness and installation availability are separate states.

1. Draft — the connection is configured but not active or billed. Ordinary client requests are blocked; guided read-only setup tests run separately before activation.
2. Enabled — reviewed, active tools are available subject to personal credentials, team access, and policy checks.
3. Disabled — the connection is paused. Existing credentials remain encrypted but ordinary client requests are not routed. Disabled connections are not billed.

Built-in providers vs custom MCP servers

The directory includes GitHub, Jira, Slack, Gmail, Google Drive, Google Docs, Google Calendar, Linear, Notion, Sentry, and Custom MCP. Available authentication and tools depend on the provider and deployment. Follow the connection setup guide; a directory entry or OAuth sign-in alone does not establish activation readiness.

Understand the checks behind Enabled

Activation ties together several independent facts. Provider consent establishes an authentication relationship. Tool discovery returns a catalog. Permission review and validator release establish which discovered capabilities can be used. A read-only test checks the current context before the administrator accepts activation.

Changing the relevant context can make an earlier test or approval unusable. Follow the current status shown by the connection guide, especially after a credential, tool, membership, or policy change. Do not use a historical successful request as proof that the current installation can be enabled.

Example: one provider, two installations

Suppose Engineering and Support need separate access boundaries to the same provider. They can use separate configured connections and assign each to the appropriate team. Each enabled, verified production installation counts separately toward connection quantity, subject to the organization’s free allowance.

Adding people or reviewed tools to one configured connection does not create additional billable units. The decision to create another installation should follow the authentication and access boundary you need, rather than the number of repositories or projects your team can see.

Check these details when access differs between people

Start by comparing the installation, team assignment, and personal provider state rather than changing organization policy immediately.

• Is the connection enabled and verified in the intended environment?
• Does the person belong to at least one assigned team, or is the connection organization-wide?
• Has the person disconnected access or lost the required provider authorization?
• Is the requested tool active, reviewed, and permitted for that resource?