Understanding Gateways and Connections in MCP Manager

Introduction to Gateways

A gateway is the central building block of MCP Manager. It bundles one or more MCP servers together behind a single URL, and layers authentication, logging, security policies, and access controls on top. When your AI application — whether it's Claude, Cursor, or a custom agent — connects to MCP Manager, it connects through a gateway.

Why Use a Gateway Instead of Connecting Directly?

Without MCP Manager, each AI application connects directly to each MCP server. This works for a single developer experimenting on their own machine, but it quickly breaks down in a team or enterprise setting:

No visibility — There's no centralized way to see which tools your team is using, how often they're called, or what data is flowing through them.
No access control — Every user has unrestricted access to every tool on every server they can reach.
No security guardrails — Sensitive data can flow freely between AI systems and MCP servers without any inspection or filtering.
Credential sprawl — Each user stores API tokens and secrets locally, often in plaintext configuration files.

A gateway solves all of these problems by acting as a managed middle layer. Your AI applications connect to the gateway URL, and MCP Manager handles routing, authentication, policy enforcement, and logging for every request that passes through.

How to Structure Your Gateways

There's no single right way to organize gateways — MCP Manager gives you flexibility to match your organization's structure and needs. Here are three common approaches:

By Use Case

Create a gateway for each workflow or project. For example, a "Frontend Engineering" gateway might include Atlassian/Jira for ticket tracking and Context7 for code documentation, while a "Product Feedback" gateway connects to Intercom for customer support data. This keeps each gateway focused and makes it easy to apply use-case-specific policies. Or separate high-risk access from low-risk so that you only expose write or destructive tools to specific users.

By Team

Create a gateway per team or department. An R&D team gets a gateway with the servers they need, while marketing gets a different set. This maps cleanly to your RBAC model since gateways are assigned to teams — users only see the gateways their team has access to.

For simpler implementations, we recommend making 1 gateway for each team and using just the base gateway URL ("https://mcp.mcpmanager.ai/gateway/v1/mcp") in your LLM/IDE/client. This reduces the number of gateways that are present in your IDE and only shows 1 pathway for your users to connect with MCP Manager.

One Gateway for Everything

For smaller organizations or simple setups, you can put all your MCP servers behind a single gateway. This is the simplest configuration, but keep in mind that performance can degrade if the total number of enabled tools grows beyond approximately 40. This is a recommended limit from major AI providers — when an AI model receives too many tool definitions, it consumes more tokens per request, increases latency, and can reduce accuracy in tool selection. If you're approaching this threshold, consider splitting into multiple gateways or using tool provisioning to limit which tools are active.

Gateway Details

Gateway URL and Protocol

Every gateway has a unique HTTPS URL. This is the URL you add to your AI client's configuration — the same way you'd add any other MCP server. MCP Manager gateways use the Streamable HTTP transport protocol (the current MCP standard) and support dynamic client registration (DCR), which means your AI client can authenticate with MCP Manager automatically through a browser-based OAuth flow. There's no manual token copying required for interactive use.

The gateway URL looks something like:

https://mcp.mcpmanager.ai/gateway/v1/mcp?gateway=CSO-xxxxxxxx

You can find this URL on the gateway's overview page in MCP Manager and copy it directly into your client configuration.

Assigned Servers

A gateway doesn't do anything on its own — it needs MCP servers assigned to it. You assign servers to a gateway through the Servers tab on the gateway detail page. The same server can be assigned to multiple gateways, and each gateway can have multiple servers. This many-to-many relationship means you can reuse server configurations across different gateways while maintaining separate policies and access controls for each.

When you assign a server to a gateway, you also configure its identity scheme — this controls how users authenticate with that specific server:

Personal (Bring Your Own Identity) — Each user must authenticate individually with the server. When a user connects through the gateway for the first time, they'll be prompted to provide their own credentials (via OAuth or token). This is the most common setting and ensures every request is tied to an individual user's access level.
Shared Identity — A single pre-authenticated identity is used for all users connecting through the gateway. This is useful for service accounts or shared resources where individual authentication isn't necessary or practical.

Gateway Logging

Every request that passes through a gateway is logged with detailed metadata — including which tool was called, who called it, which server handled it, the duration, token counts, and more. You can view these logs directly from the Logging tab on the gateway detail page. Logs are available for filtering, export, and can be forwarded to external systems via OpenTelemetry.

Adding a Gateway to Your Client

An important thing to understand about MCP Manager's architecture: to your AI client, a gateway is an MCP server. You add MCP Manager to Claude, Cursor, or any other MCP-compatible application the same way you'd add any other MCP server — by providing a URL and transport type.

For example, in a mcp.json configuration file:

{
  "mcpm-slack-gateway": {
    "url": "https://mcp.mcpmanager.ai/gateway/v1/mcp?gateway=CSO-xxxxxxxx",
    "type": "http"
  }
}

Or using the Claude Code CLI:

claude mcp add transport -http mcpm-atlassian https://mcp.mcpmanager.ai/gateway/v1/mcp?gateway=CSO-xxxxxxxx

Once added, your client will initiate the connection and authentication flow automatically.

Gateway Policies

Gateways aren't just routing layers — they're also enforcement points. MCP Manager provides three categories of policy controls that let you govern what flows through each gateway.

Tool Provisioning

Tool provisioning gives you fine-grained control over which tools, resources, and prompts are exposed through a gateway. When an MCP server is assigned to a gateway, MCP Manager discovers all of its available features (tools, resources, prompts, and resource templates). You can then selectively enable or disable individual features.

This is useful for several reasons:

Cost control — Every tool definition that reaches your AI client consumes tokens. Disabling tools your team doesn't need reduces per-request costs.
Performance — Fewer tools means faster responses and more accurate tool selection by the AI model.
Focus — If a server exposes 50 tools but your team only needs 5, you can hide the rest so they don't clutter the AI's context.

Tool provisioning also includes rug pull protection. When you first approve a server's tools, MCP Manager takes a snapshot of each tool's name and description. If a tool's name, title, or description changes after approval — which could indicate a supply chain attack where a previously safe tool is replaced with a malicious one — MCP Manager can automatically disable that tool and alert administrators. This protects against scenarios where an upstream MCP server silently changes its behavior.

Rules

Rules are content-level policies that inspect the data flowing through a gateway and take action when specific patterns are detected. Rules are configured per gateway and can alert, block, redact, replace, mask, or hash matched content. MCP Manager supports three types of rule engines:

Regex Rules

Define custom regular expression patterns to detect sensitive content in MCP traffic. Common uses include matching phone numbers, social security numbers, API keys, internal project IDs, or any other patterns specific to your organization. You can create multiple patterns per rule and configure what action to take when a match is found — block the request entirely, redact the matched content, replace it with a placeholder, or simply log an alert.

Presidio Rules

Powered by Microsoft Presidio, these rules use pre-trained NLP models to detect personally identifiable information (PII) across a broad range of entity types — names, email addresses, phone numbers, credit card numbers, physical addresses, and more. Presidio rules go beyond simple pattern matching by using contextual analysis to reduce false positives. You can configure which entity types to detect, set confidence thresholds, and define allow lists for known-safe values.

Custom DLP or Guardrail via API

For enterprise customers with existing data loss prevention infrastructure, MCP Manager can integrate with external DLP platforms and LLM guardrails (such as AWS Bedrock) via API or webhook. This lets you apply your organization's existing content policies to MCP traffic without duplicating rule configurations. MCP Manager passes the request or response to your external system and enforces the result — allowing you to bring your own rules engine.

All rule types support an alert-only mode that lets you test new policies against live traffic without blocking any requests. This makes it safe to roll out new rules gradually and build confidence before switching to enforcement.

RBAC (Role-Based Access Control)

MCP Manager implements role-based access control to govern who can access which gateways — and by extension, which MCP servers and tools.

Access is managed through teams. Administrators create teams, assign users to them, and then assign gateways to those teams. A user can only see and connect to gateways that belong to their team. Users can belong to multiple teams, and gateways can be assigned to multiple teams — giving you the flexibility to model complex organizational structures.

Administrators can also delegate authority through customizable roles with fine-grained permission grants. This means you can allow a team lead to manage their own gateway's tool provisioning without giving them access to modify security policies or manage other teams' gateways.

For organizations using enterprise identity providers, MCP Manager supports SSO (via Okta, Entra ID, and others) and SCIM for automated user provisioning and de-provisioning. When SCIM is enabled, team membership stays in sync with your identity provider — when someone joins a team, changes roles, or leaves the organization, their MCP Manager access updates automatically.

Connections

What is a Connection?

A connection represents an individual pathway between an AI client and a gateway. Think of it this way: you might have Claude Code on your laptop connected to your "Engineering" gateway, and also connected to your "Product Feedback" gateway — that's two connections. Your colleague might also be connected to the "Engineering" gateway from their Cursor instance — that's a third connection.

Connections are the many-to-many relationship between clients and gateways. Each connection has a specific user (or host) attached to it, along with the authentication state for every server in that gateway. Connections can be individually enabled or disabled, and each one generates its own logs.

Two Ways to Connect

MCP Manager supports two methods for establishing a connection, depending on whether a human user or an automated system is connecting.

1. Dynamic Client Registration (DCR) — For Interactive Use

This is the standard method for human users connecting from AI clients like Claude Code, Cursor, or any other MCP host that supports OAuth. Here's how it works:

Add the gateway URL to your client — Copy the gateway URL from MCP Manager and paste it into your AI client's MCP server configuration.
Your client initiates the connection — When your client starts, it contacts the gateway URL and kicks off OAuth dynamic client registration. A browser window opens automatically.
Select a gateway — The authorization screen shows you which gateways are available to you (based on your team membership). Select the one you want to connect to. If the URL already specifies a gateway, this step may be pre-selected.
Authenticate with each server — The wizard walks you through authenticating with each MCP server assigned to the gateway. Depending on the server's configuration, you may be:
- Redirected to the application's website to authorize access via OAuth (e.g., clicking "Approve" on Atlassian's authorization page)
- Asked to provide an API token or bearer token
- Automatically connected if the server uses open authentication or a shared identity
Confirm and redirect — After authenticating with all servers, you confirm the connection. Your browser redirects back to your AI client, which completes initialization and begins receiving tools from the gateway.

This entire flow happens once per connection. MCP Manager manages token refresh automatically, so you shouldn't need to re-authenticate unless a token is revoked or expires without a refresh mechanism.

2. API Access Token — For Agents and Headless Connections

Automated agents, CI/CD pipelines, and other non-interactive systems can't open a browser to complete an OAuth flow. For these use cases, MCP Manager provides token-based authentication through the Apps & Agents section of the product.

Here's how to set up a headless connection:

Create an API access token-based host — In the Apps & Agents page, click "Add API access token-based host" and give it a name that identifies the system (e.g., "CI Pipeline Agent" or "Customer Support Bot").
Add a connection — Within that host, create a new connection.
Select a gateway — Choose which gateway this agent should connect to.
Authenticate with each server — Just like the interactive flow, you'll authenticate with each server in the gateway. For headless setups, this typically means providing API tokens or using shared identities.
Confirm — Complete the setup.
Receive your URL and secure token — MCP Manager generates a gateway URL and an API access token. This token allows the agent to connect directly to the gateway without going through the browser-based DCR flow. Store this token securely — it provides direct access to the gateway and its servers.

You then configure your agent to use this URL and token in its MCP client configuration. The token is long-lived and designed for programmatic access.

Managing Connections

All active connections are visible in two places:

On the gateway detail page — The Connections tab shows every connection to that specific gateway, including which user or host created it, when it was established, and whether it's currently active.
On the Apps & Agents page — Shows all hosts (both interactive clients and token-based agents) and their connections across all gateways.

Each connection can be individually disabled without affecting other connections to the same gateway. This is useful for revoking a specific user's access or shutting down a misbehaving agent without disrupting everyone else.

Connections also have their own logs, making it possible to audit exactly what happened through a specific client-to-gateway pathway. You can see which tools were called, when, by whom, and whether any policies were triggered.

Troubleshooting Inactive Connections

If a connection becomes unresponsive or tools stop working, here are the most common steps to resolve it:

Check the Alerts page — A good first place to check if something isn't working is the Alerts page (if you have access to it). The alerts page will tell you if an identity failed to refresh or if something else is wrong. Find the alerts page on the top left hand side of your navigation in app.mcpmanager.ai.
Refresh your identity — Navigate to the identity detail page for the affected server in MCP Manager and refresh it. This forces a token refresh and verifies the connection to the upstream server is still valid.
Reconnect from your client — In your AI application, reconnect the MCP server. Depending on your client, this might mean clicking a "Connect" button if the connection has lapsed, toggling the connection off and back on, or renaming the server entry in your mcp.json file and saving (this triggers a fresh connection attempt).
Create a new identity — If refreshing doesn't resolve the issue, try creating a brand-new identity for the affected server and gateway combination. This starts the authentication flow from scratch.

If none of these steps resolve the issue, you can reach out to MCP Manager support using the "Get help" option in the bottom-left corner of the application.