> ## 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.
# 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](/mcp-gateway-concepts/mcp-servers/overview) 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](/deployment/rbac-and-roles/capabilities).
## 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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
C1["🤖
Client A"] --> S1["🖥️
GitHub"]
C1 --> S2["🖥️
Jira"]
C1 --> S3["🖥️
Internal DB"]
C2["🤖
Client B"] --> S1
C2 --> S4["🖥️
Slack"]
C2 --> S3
C3["🤖
Client C"] --> S2
C3 --> S4
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
class C1,C2,C3 client;
class S1,S2,S3,S4 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.**
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
C1["🤖
Client A"] --> GW
C2["🤖
Client B"] --> GW
C3["🤖
Client C"] --> GW
GW["🛡️
MCP gateway
one URL"] --> S1["🖥️
GitHub"]
GW --> S2["🖥️
Jira"]
GW --> S3["🖥️
Notion"]
GW --> S4["🖥️
Slack"]
GW --> S5["🖥️
Internal DB"]
GW -.-> LOG[("🗄️
Audit log")]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px;
class GW gateway;
class C1,C2,C3 client;
class S1,S2,S3,S4,S5 server;
class LOG datastore;
```
You assign servers to a gateway, provision the gateway to the [teams](/deployment/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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TB
In["Request from client"] --> Auth["1 — Authenticate the caller"]
Auth --> Authz["2 — Authorize
which servers & tools are allowed"]
Authz --> Rules["3 — Apply rules
tool allow/deny · PII redaction · guardrails"]
Rules -->|"write tool not permitted"| Block["🚫
Blocked — returned as an error"]
Rules --> Route["4 — Route to the upstream server"]
Route --> Resp["5 — Inspect & redact the response
e.g. mask a leaked secret"]
Resp --> Log[("🗄️
6 — Log request & response")]
Log --> Out["Response to client"]
classDef blocked fill:#ec9c9d,color:#12141d,stroke:#eb5757,stroke-width:2px;
classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px;
class Block blocked;
class Log datastore;
```
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](/features/gateway-rules/overview) 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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','actorBkg':'#aed8ff','actorBorder':'#0b4880','actorTextColor':'#062b4c','signalColor':'#6a6b76','signalTextColor':'#12141d','noteBkgColor':'#fff8e4','noteBorderColor':'#ffa535','noteTextColor':'#12141d'}}}%%
sequenceDiagram
participant C as 🤖 Client
participant G as 🛡️ MCP gateway
participant U as 🖥️ Upstream server
C->>G: tool call (one MCP request)
G->>G: authenticate & authorize
G->>G: apply rules (allow/deny, redact)
Note over G: write to audit log
G->>U: forward with brokered identity
U-->>G: tool result
G->>G: inspect & redact response
Note over G: write to audit log
G-->>C: governed result
```
## 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](/enterprise/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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
Client["🤖
Client (Claude, ChatGPT, Cursor)"] -->|"OAuth via your IdP / SSO
same for every client"| GW["🛡️
MCP gateway"]
GW -->|"per-user OAuth"| S1["🖥️
Upstream A"]
GW -->|"shared service account"| S2["🖥️
Upstream B"]
GW -->|"manual token / endpoint"| S3["🖥️
Upstream C"]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
class GW gateway;
class Client client;
class S1,S2,S3 server;
```
Whether a given server uses a per-user or shared identity is the server's **identity scheme** on that gateway. See [the identities model](/mcp-gateway-concepts/mcp-servers/overview#how-identities-control-access-across-all-three-types) 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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
subgraph Upstreams["Upstream servers and their tools"]
direction TB
T1["🖥️
GitHub: list_repos · create_issue · delete_repo"]
T2["🖥️
Jira: search · create_issue · delete_project"]
end
Upstreams --> GW["🛡️
MCP gateway
admin curates exposed tools"]
GW --> Client["🤖
Client sees one filtered toolset:
list_repos · create_issue · search"]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
class GW gateway;
class Client client;
class T1,T2 server;
style Upstreams fill:transparent,stroke:#9ca1ab,stroke-dasharray:4 3,color:#6a6b76;
```
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](/features/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](https://app.mcpmanager.ai/settings/gateways).
## Further reading
How clients connect to a gateway and appear in your workspace.
The Remote, Managed, and Workstation servers a gateway aggregates.
The detection methods and actions applied to traffic in the path.
How provisioning a gateway to a team grants users access to it.