Skip to main content

Manage connectors

A connector is an MCP server available through the Connector Gateway. After registering a connector, grant access to it through its connector policy.

The connector list​

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

Where connectors come from​

Select Add connector and choose how to register the connector:

  • Import from registry adds remote servers that your curated MCP registry publishes.
  • Discover in Kubernetes scans your cluster for running MCP servers and lets you choose which ones to add.
  • Configure manually registers a server by name, endpoint, and transport.

Add MCP servers from your cluster​

Discovery lists every MCPServer resource in your cluster, across all namespaces, as a candidate. Nothing is registered until you select candidates and choose Add to catalog.

Each candidate shows its namespace, transport, and endpoint. If an existing connector already uses a candidate's endpoint, the candidate shows Already added as and the connector's name. A candidate that belongs to an MCP server group shows that group, because a vMCP might already aggregate it and adding it separately would expose its tools twice. If discovery can't determine a candidate's transport, choose one before adding it.

Each server you add becomes a Draft connector with no backend authentication and a description naming the namespace it came from. Open the connector to review its configuration, then save it to publish the connector.

Draft, available, and failure​

Draft connectors are registered but inactive. Activating a connector triggers an endpoint check. A valid MCP endpoint becomes Available; an invalid or unreachable endpoint enters Failure.

Granting access​

Each connector has a connector policy that decides who can use it. The policy has two authoring modes:

  • Structured mode grants access to directory groups. This is the mode the console manages.
  • Cedar mode uses a Cedar policy document. A document can match directory group (UserGroup) membership, custom claims from the caller's token such as principal.claim_department, or both.

To grant access in structured mode, open a connector and use Grant access to add one or more groups. Membership is inherited, so granting to a parent group reaches every subgroup beneath it. Directory groups are separate from the OIDC claim groups that cluster authorization policy matches. See Directory groups and OIDC claim groups.

The console doesn't edit Cedar-mode policies. For a Cedar-mode connector, it shows a notice and disables group editing. Switch modes and write Cedar documents through the connector policy routes of the Enterprise Manager API.

The Connector Gateway evaluates access on every request, so changes take effect on the next request.

Connector authentication​

A connector can broker OAuth through an identity provider when it needs user authorization for its backend.

Users complete consent in Your workspace or during client connection. The Connector Gateway stores the authorization and prompts the user to Re-authenticate after it expires.

Next steps​