Connect a server
Three flows put a service within an agent’s reach: an administrator enables a server for the organization, each member connects their own account to it, and — for anything not in the catalog — an administrator adds a custom MCP server by URL.
Enable a catalog server (administrators)
Settings → MCP Registry lists the catalog. Open a server’s panel and flip the enable toggle. Most OAuth servers are ready immediately; some show Needs setup with a per-server checklist — registering an OAuth client, filling server variables, or installing an app. The panel walks through exactly what each one needs.
Enabling a server makes it connectable; it grants nothing by itself. Its tools still need a policy decision before any agent can call them.
Connect your account (everyone)
Connected Services lists every enabled server that takes a personal connection. Connect sends you through the service’s own sign-in and consent screen, and from then on agents acting for you use that connection — tools authenticate as you, and see what you can see.
You can also connect mid-conversation: the chat input’s service picker offers Connect more services, and a planning agent that needs an unconnected service will say so and offer the connection inline. Disconnect removes the credential immediately; a run that loses its connection mid-flight pauses with a reconnect prompt rather than failing.
Add a custom server (administrators)
Anything that speaks MCP over HTTP can join the registry. Add custom server in the MCP Registry is a two-step wizard:
Describe the server
A display name, the remote endpoint URL, the transport (Streamable HTTP or SSE), and a description your team will recognize.
Choose how agents authenticate
Three modes: OAuth — the wizard runs discovery against the server and reports whether it can self-register a client or needs one pre-registered; Custom credentials — HTTP headers you supply, with sensitive values write-only from the moment they’re saved; or No authentication for open servers.
Once created and enabled, a custom server behaves exactly like a catalog entry: its tools appear after a refresh, they need policy decisions, and its calls land in the audit log. This is also the pattern for keeping environments apart — production and staging as two servers with distinct URLs — and the primary extension point for anything the catalog doesn’t cover.
A server’s tool list is fetched, not live. After a server adds or changes tools, use Refresh in its registry panel so agents and policies see the current set.