Connection Experience

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

Connecting to a gateway is the first thing an end user does in MCP Manager, and it’s designed to be a short, guided round trip: you paste one URL into your AI client, the client sends you to MCP Manager to authorize, you bring an identity for each server that needs one, and you land back in your client with the tools ready. This page describes that experience from the user’s chair.

​

The tab that opens back to MCP Manager

Say you’re connecting in Claude. You add the gateway’s URL as a custom connector; because the gateway requires authorization, Claude can’t use it immediately and instead opens a browser tab to MCP Manager so you can authorize. (Every client does the equivalent — the gateway responds that authorization is needed, and the client hands you off to MCP Manager.) You land on the MCP Manager authorization screen, signing in through your organization’s SSO if you aren’t already. From here, MCP Manager walks you through everything needed to connect, and at the end it sends you straight back to your client.

​

MCP Manager confirms which gateway you’re connecting

The authorization screen already knows which gateway you’re connecting — it’s carried in the URL your client used — so it selects that gateway for you. If you connected with a general “picker” URL instead of a gateway-specific one, you choose from the gateways your team membership grants. (The two URL modes are covered in Gateway Deployment Strategies.)

​

Only the apps your administrators allow can connect

MCP Manager validates the app or agent you’re connecting from — what it calls a host. Administrators decide which apps are allowed, and if an app has been disabled, any attempt to connect or call through it is rejected before it reaches a server. This is how an organization standardizes on some clients and not others — for example, allowing Claude while blocking ChatGPT. The check isn’t a one-time gate at sign-up: a host’s allowed status is enforced on every request, so an administrator can cut off an app at any moment and the change takes effect immediately, without deleting anything. The practical result for you is simple — you can connect through the apps your administrators permit, and only those.

​

It guides you through each server

A gateway usually bundles several MCP servers, and MCP Manager steps you through exactly what each one needs — no more, no less:

• Servers set to a shared identity need nothing from you. The administrator already attached a service-account credential, so they’re ready the moment you connect and you’re never prompted.
• Servers set to per-user identity ask you to bring your own identity for that server (see Identity Controls). You’re prompted once per such server, with a progress indicator showing where you are.
• A bundled server container also asks you to pick which server instance you’re connecting to before you choose an identity.

You can’t finish the flow until every server that requires something from you has it, so by the time the screen lets you complete, you’re fully connected — there’s no ambiguous half-connected state where some tools silently fail later.

​

Connect once, reuse everywhere

The clicks happen mostly the first time. When you bring an identity for a SaaS app (Notion, GitHub, Jira) or a custom MCP server, you authorize it once — through that provider’s OAuth consent screen, or by providing a token — and MCP Manager saves the resulting identity for you. After that, the identity is offered as a ready-to-pick option whenever you connect a gateway that includes the same server, so you select it instead of authorizing again. MCP Manager refreshes the underlying OAuth tokens automatically, so a saved identity keeps working without you re-authenticating each session. In practice, your second and later connections to the same servers are nearly click-free — the flow only stops to ask about servers you haven’t connected before.

​

When you’re done

Once every required server has an identity, you complete the authorization, MCP Manager hands you back to your client, and the tab closes on its own. Your client finishes connecting and the gateway’s tools appear, ready to use — each call from then on running under the identity you brought and recorded in your logs.

​

The same flow for token-based hosts

Headless agents that connect with an API token instead of OAuth — see Agents that Pass Identities to MCP Manager — enroll through the same authorization screen described here. A user still opens the connection, confirms the gateway, and brings an identity for each per-user server in the same guided, reusable way. The only difference comes at the end: instead of an automatic OAuth handoff back to an app, MCP Manager issues an API access token for the agent to use. Everything about confirming the gateway, validating the host, and stepping through identities is identical.

​

Further reading