Skip to main content

Manage connectors

A connector is an MCP server the platform makes available through the MCP gateway. Registering one here does not expose it to anybody: access is granted per group, so a newly added connector is visible to nobody until you grant it.

The connector list​

The Connectors screen lists every registered connector with its endpoint, transport, verification state, the number of groups that have access, and when it was created.

The Groups with access column is the one to scan. A connector showing zero is registered but unreachable by anyone, which is either deliberate staging or an oversight.

Where connectors come from​

Three routes, and the list shows which one applies:

  • Import from registry pulls a server from your MCP registry, so the catalog your platform team curates is the starting point rather than hand-entry.
  • Add connector registers one directly by endpoint.
  • Discovery picks up MCP servers running in your cluster automatically. Those arrive with a description noting the namespace they were found in.

Discovered connectors are the ones worth reviewing: something appearing in the list because it exists in a namespace is not the same as something an administrator chose to offer.

Verification state​

A connector is either verified or a draft. Verification reflects whether the platform has confirmed the endpoint behaves as an MCP server. A draft is registered but unconfirmed, which is the normal state immediately after adding one and a signal to investigate if it persists.

Granting access​

Open a connector and grant it to one or more groups. Membership is inherited, so granting to a parent group reaches every subgroup beneath it. That is usually the right level: it gives you one place to change access when a team's shape changes.

Access grants take effect on the user's next request. A developer whose group was just granted a connector sees it appear in their own connector list without re-authenticating.

warning

Access is granted to directory groups, not to the OIDC claim groups that cluster-level authorization policy matches on. See The two group models.

Connector authentication​

A connector that needs to reach a backend on the user's behalf brokers OAuth against an identity provider. Configure that on the connector, referencing an identity provider and a managed secret you have already created.

The user completes the upstream sign-in once, from their own connector list, and the gateway holds the resulting authorization for their subsequent tool calls.

Next steps​