MCP Gateways

What an MCP gateway is in MCP Manager: one governed URL that aggregates many upstream MCP servers, applies authentication, authorization, and rules to every request and response in the path, and logs everything — plus how clients and upstreams authenticate separately and how the same server can be added with different identities and policies.

An MCP gateway in MCP Manager is one governed endpoint — a single URL — that sits between your AI clients and many upstream MCP servers. A client connects to the gateway once; the gateway aggregates the servers behind it, applies your rules to traffic as it passes through, and logs every request and response. Three ideas do the work: one front door (connect once), many servers behind it (aggregation), and rules applied in the path (governance and observability).

Throughout this page, a client is an AI app such as Claude, ChatGPT, or Cursor; an upstream MCP server is one of the servers the gateway aggregates (GitHub, Jira, Notion, Slack, an internal database); and the gateway is the governed URL in the middle.

Creating and using gateways is gated by capabilities. Basic gateway management lets a role create gateways, assign servers, and set each server’s identity scheme; View and use all gateways grants access to every gateway in the workspace. If you don’t see the Gateways section or a particular gateway, your role doesn’t have the relevant capability — ask a workspace administrator to grant it. See the capabilities reference.

Why a gateway: the problem of ungoverned sprawl

Without a gateway, every client wires up to every MCP server directly. Credentials are scattered across machines, there is no single place to apply policy, and no one can see what AI is doing with which tool — this is “shadow MCP.” The mesh gets worse with every new client and every new server.

A gateway replaces that tangle with one controlled path.

One front door, many servers

A gateway gives every client one URL to connect to, and fans out to the many upstream servers assigned to it. Clients never see the individual servers or their credentials — they see a single endpoint that exposes a unified set of tools. The unit to keep in mind: one gateway = one URL = a governed bundle of servers and rules.

You assign servers to a gateway, provision the gateway to the teams that should use it, and hand out the one URL. Adding or removing a server changes what every client can reach, without anyone reconfiguring their client.

A gateway is more than a proxy

A plain proxy forwards traffic. A gateway forwards, governs, and observes: it authenticates the caller, decides which servers and tools they may reach, runs your rules on the request and the response, brokers the right identity to each upstream, and writes an audit log entry at every hop. That difference — enforcement and inspection on every call — is the entire point. If a gateway only forwarded, it would be a proxy.

Inside the gateway: the governance pipeline

Every request runs through an ordered pipeline before and after it reaches an upstream server. The gateway is not a passthrough — it inspects and acts on every request and every response.

The same rules engine runs on the way out and the way back: a disallowed tool call is blocked and returned as an error, and sensitive data in a response — a PII field, a leaked secret — is redacted before it reaches the client. See gateway rules for the detection methods and actions.

The lifecycle of a request

Governance happens synchronously, in the path of every call, and logging is always on. A single tool call travels from the client to the gateway, through the policy checks, out to the upstream server with a brokered identity, and back through response inspection — with an audit-log entry written at each hop.

Two separate authentications

A gateway brokers identity, which means there are two distinct authentications, and decoupling them is what makes the gateway flexible. Do not think of it as one auth arrow.

• Client → gateway is uniform: every client authenticates to the gateway the same way, with OAuth delegated to your organization’s identity provider / SSO (or a gateway API token for programmatic access).
• Gateway → upstream varies per server: the gateway independently presents the right credential to each upstream — a per-user OAuth identity (so actions are attributed to the individual), a shared service account, or a manual token/endpoint for servers that don’t publish standard OAuth metadata.

Whether a given server uses a per-user or shared identity is the server’s identity scheme on that gateway. See the identities model for how Private and Global identities feed these schemes.

Adding the same server more than once

A powerful consequence of brokered identity and per-assignment rules: you can add the same upstream server to a gateway more than once, each time with a different identity scheme and a different set of exposed tools and policies. Each assignment is independent.

For example, add the Atlassian server twice:

• Once with a shared service account that exposes only permissive read and search tools, so everyone can search Jira and Confluence without their own credentials.
• Again requiring each user’s own identity, exposing the write tools (create issue, edit page) — so every write to Atlassian is attributed to the actual person who made it.

The result is a single gateway where reads are frictionless and shared, while writes carry individual accountability — built entirely from how you configured two assignments of one server.

Curating which tools are exposed

Aggregation is not all-or-nothing. Upstream servers often expose many tools, and an administrator chooses which tools each assignment exposes — allow all, allow only a selected set, or expose none of a given type. Clients then see one unified, filtered toolset across the whole gateway, with each tool namespaced by its server.

This controls which capabilities are even visible to a client, on top of whether a given call is allowed to pass.

Everything is logged

Because every request and response flows through the gateway, every one is recorded. The gateway writes structured log entries for the client request, the upstream request, both responses, and any policy or tool-filtering action it took — so you always have an audit trail of what AI did, with which tool, under whose identity. See Viewing Logs for the log model and how to read a correlated request.

A gateway versus the MCP Manager platform

Keep the two levels distinct. A gateway is one governed URL — a bundle of assigned servers, identities, rules, and logs that a set of teams uses. The MCP Manager platform is the management plane where you create and operate many gateways, manage servers and identities, define rules, and review logs across the workspace. You can run several gateways at once — for example, one per department, each aggregating a different set of servers under different policies. Manage them at Gateways.

Further reading

Apps & Agents

How clients connect to a gateway and appear in your workspace.

MCP Servers overview

The Remote, Managed, and Workstation servers a gateway aggregates.

Gateway rules

The detection methods and actions applied to traffic in the path.

Teams

How provisioning a gateway to a team grants users access to it.