Why the category exists
Three servers is the threshold we keep running into. Past it, the same four questions reach the CISO's desk in sequence. Who may call which tool, under what conditions? Where is every tool call logged? How do we rate-limit? And the one that wakes people up: how do we stop handing user-level credentials to a model at inference time?
The protocol leaves those answers to you. MCP defines hosts, clients and servers, and mentions gateways only as intermediaries: the transport mirrors fields into headers so that "intermediaries (load balancers, gateways, observability tooling)" can route and inspect requests [1], and the caching rules say what a shared gateway may cache [3]. The 2026-07-28 revision made their job easier: it removed protocol-level sessions and requires an Mcp-Method header on every request and an Mcp-Name header on tool calls, so an intermediary can route a call without parsing the body [1].
Authorization itself is optional, but once an HTTP server uses it the spec sets the floor. A protected MCP server is an OAuth 2.1 resource server: it must reject tokens not issued for it, clients must name it with an RFC 8707 resource indicator [4], and it must not pass the client's token through to an upstream API [5]. Meeting those rules once, at a gateway, is cheaper than meeting them in every server.
In August 2025 Solo.io's Christian Posta and Louis Ryan called the June 2025 authorization spec "a non-starter for enterprise" for leaning on anonymous dynamic client registration, and argued for existing SSO plus a gateway [6]. Solo.io builds gateways, and the spec has since deprecated that registration path [4], but the conclusion held. On client work the arc repeats: OAuth wired per server, trouble around server five, a gateway built by hand.
MCP proxy vs MCP gateway
A proxy forwards MCP traffic. It may put several servers behind one URL, bridge a local stdio server onto HTTP, or terminate TLS, but it does not decide who may call which tool. A gateway is a proxy that makes that decision on every call and records it. Every MCP gateway is a proxy; most MCP proxies are not gateways.
The spec already binds proxies: one using a static client ID must get user consent for each dynamically registered client before forwarding to a third-party authorization server [5]. Our test is cruder: ask for the written policy that says this caller may call this tool. No policy artifact, no gateway.
| Concern | MCP proxy | MCP gateway | API gateway without MCP support |
|---|---|---|---|
| What it reads | Enough MCP to forward messages | Methods and tool names: tools/list, tools/call | HTTP routes and headers; every client message is a POST to one endpoint, and tool calls carry the tool name in an Mcp-Name header [1] |
| Who may call which tool | Not decided | Decided per tool, every call | Per route; a header rule on Mcp-Name can block a named tool, but nothing trims what tools/list shows |
| Credentials | Passes the connection on | Checks the caller's token, attaches its own downstream credential | Checks keys or JWTs for the route |
| Tool discovery | Lists every tool | Lists only what the caller may use [7] | Passes tools/list through unfiltered |
| Record | Request logs | One entry per tool call: caller, tool, decision, outcome | Request logs per route |
When you need one, and when you don't
One developer running local stdio servers against their own accounts does not need a gateway; the spec tells stdio servers to take credentials from the environment [4]. You need one when any of these is true.
- More than three MCP servers are shared. Per-server OAuth, logs and rate limits stop being manageable.
- Several clients call the same servers. Claude, Copilot, Cursor and an in-house agent should meet one policy, not four configurations.
- Users would otherwise paste tokens into a client config. That credential belongs on the gateway.
- Any server touches regulated data. PHI, cardholder data or customer PII needs a record of who called which tool, when, under which policy.
- Access must be revocable in one step, for a user or a tool, across every server.
Who ships MCP gateways, October 2026
Since our April edition, two independents changed hands and the protocol went stateless: 2026-07-28 dropped protocol-level sessions, so gateways that pinned calls to a session had to change how they route [1]. The table now also covers Microsoft and Google.
Rows are shapes, not rankings, each checked against the vendor's own pages on October 11, 2026. To choose, use the MCP gateway hub; for scores, see our ten-gateway documentation audit, which scores our own product alongside the rest.
| Vendor | Shape | What ships |
|---|---|---|
| Amazon Bedrock AgentCore Gateway | Hyperscaler (AWS-hosted) | GA October 13, 2025, when it also began fronting existing MCP servers [2]. Turns Lambda, OpenAPI and Smithy into MCP tools, passes A2A traffic through, routes LLM inference; inbound and outbound auth [8]. |
| Azure API Management | Hyperscaler (Azure-hosted or self-hosted gateway) | Exposes a REST API as an MCP server, or governs an existing one with JWT, rate-limit and IP policies. Tools yes, prompts no [9]. |
| Google Agent Gateway | Hyperscaler (Google Cloud) | Entry and exit point for agent traffic in Gemini Enterprise Agent Platform, including calls to third-party MCP servers, under IAM and Model Armor policies [10]. |
| Cloudflare MCP server portals | Zero Trust SaaS (Cloudflare One) | GA September 24, 2026: one endpoint for approved MCP servers, with Cloudflare Access logging tool activity [11]. On Cloudflare's own internal portal, four servers' 52 tools (about 9,400 tokens) collapsed into 2 (about 600) with Code Mode on, a 94% cut [12]. |
| Kong AI Gateway | API gateway that added MCP | Enterprise plugin with per-tool allow and deny lists and an audit log of every attempt [13]. A2A via Agent Gateway, GA in AI Gateway 3.14, announced April 14, 2026 [14]. Kong's AI Gateway changelog lists 2.1.0 (September 22, 2026) as adding MCP revision 2026-07-28 [15]. |
| Composio | Integration platform that added a gateway | 1,500+ managed toolkits plus your own MCP servers behind per-team endpoints; SSO, SCIM, action-level access control, metadata-only audit records [16]. |
| Bifrost (Maxim AI) | LLM gateway that added MCP | Apache 2.0; an MCP client to servers and an MCP server to agents [17]. Its 11 µs overhead was measured at 5,000 RPS against mocked OpenAI calls on an AWS t3.xlarge, excluding JSON marshalling and HTTP calls; it is not an MCP tool-call benchmark [18]. |
| agentgateway; IBM ContextForge | Open source, self-hosted | agentgateway: Linux Foundation project, Apache 2.0, MCP and A2A, RBAC in the CEL policy language [19]. ContextForge: IBM's open-source gateway, GA at v1.0.0 on May 1, 2026, with A2A [20]. |
| Portkey; Lunar.dev | Independents that changed hands in 2026 | Portkey: acquired by Palo Alto Networks on May 29, 2026, and now the core AI gateway of Prisma AIRS [21]. Lunar.dev: acquired by Boomi, per Boomi's July 27, 2026 post; its AI gateway becomes part of the Boomi Enterprise Platform [22]. |
| Zuplo; Docker MCP Gateway | API gateway that added MCP; open-source proxy | Zuplo: MCP Gateway in public beta June 2, 2026, now generally available, with OAuth, credential brokering, tool curation and observability [23]. Docker: open-source proxy that orchestrates your MCP servers and manages their configuration, credentials and access control; the version inside Docker AI Governance is invite-only [24]. |
| Jarvis Registry (ASCENDING, this site's publisher) | Customer-hosted registry + gateway | Runs in the customer's AWS or Azure environment (EKS/AKS guide). One permission-scoped Registry Endpoint; RBAC plus per-tool ACLs; registers Streamable HTTP servers and legacy SSE servers, a transport the spec has deprecated [1]. OpenTelemetry and Prometheus metrics cover MCP activity and latency, but the docs do not specify per-call payload or policy-snapshot logging [25]. No SOC 2, HIPAA or FedRAMP attestation is claimed [26]. |
What a serious gateway has
- Per-tool policy as code. Versioned and reviewable. AgentCore writes it in Cedar [27]; Kong in plugin configuration [13].
- Credential brokering. The gateway holds the Snowflake PAT, the Jira token, the SharePoint secret. The user never pastes them; the model never sees them.
- Permission-scoped discovery. The spec lets
tools/listreturn only what the caller may use [7]. An agent should never see a tool it cannot call. - Per-tool observability. Latency, errors and volume per tool, traceable to a conversation, ideally in OpenTelemetry's GenAI conventions.
- Egress control. Region-locked routing and PII redaction, the chokepoint where you can show regulated data stayed in region.
- A way to find what bypasses it. Cloudflare documents scanning for MCP traffic that skips its portals [12]; ask every vendor how they find unregistered servers.
- Federated targets. Ask what happens when a tool is itself another MCP server or an agent. The spec says proxies that aggregate servers should disambiguate colliding tool names, for example by prefixing them with a server identifier [7]; AgentCore, Kong, agentgateway and ContextForge also front agent-to-agent (A2A) traffic [8][14][19][20].
MCP gateway, the common questions
-
What is an MCP gateway and do I need one?
An MCP gateway is the control point between MCP clients and MCP servers: it authenticates the caller, authorizes each tool call, attaches the downstream credential, routes the call and logs it. An MCP server exposes one system's tools; the gateway sits in front of many servers and, to a client, looks like one server that lists only what that caller may use [7]. You need one once more than three servers are shared across users or clients, as soon as any server touches regulated data, or when users would otherwise paste tokens into client configs. A single developer running local stdio servers does not; the spec has stdio servers read credentials from the environment [4]. -
What is the difference between an MCP proxy and an MCP gateway?
A proxy moves MCP traffic; a gateway rules on it. Putting several servers behind one URL, bridging stdio to HTTP or terminating TLS are proxy jobs. A gateway adds a decision on every call (this caller, this tool, this credential) and keeps a record of the outcome. Ask the vendor for its written per-tool policy. If there is nothing to read, you are looking at a proxy. -
Is an MCP gateway the same as an API gateway?
No. An API gateway authorizes HTTP routes; an MCP gateway authorizes tools. Every client message over Streamable HTTP is a POST to one endpoint. Since the 2026-07-28 revision the tool name also travels in anMcp-Nameheader, so a header rule can block a named tool, but a plain API gateway still cannot trimtools/listto what the caller may use or attach a per-tool downstream credential [1]. Azure API Management and Kong now add MCP features to their API gateways [9][13]. An LLM gateway routes prompts to models instead, and an agent gateway also covers agent-to-agent traffic; see our agent gateway vs API gateway comparison. -
How do I control which users can call which MCP tools?
Put the rule at an MCP gateway rather than in each server. The gateway authenticates the user against your identity provider, evaluates a per-tool policy (this caller, this tool, these conditions) on everytools/call, and can trimtools/listso each user sees only what they may call [7]. Hiding a tool is not enforcement, so test a direct call to a hidden tool and check that the denial lands in the audit record. Per-server OAuth can do the same job for a handful of servers; past that, one policy layer is easier to review and to revoke.