MCP Gateway: What It Is and How to Choose One

On this page

MCP Gateway: What It Is, When You Need One and How to Choose (Nov 2026)

An MCP gateway is a proxy between your AI apps and your MCP servers. Clients connect to one endpoint. The gateway signs users in, decides which tools each person can see, keeps the API keys on its side, logs every call and forwards it to the right server. You need one when a team shares many servers. One person with two servers usually doesn't.

What an MCP gateway does

Without a gateway, every person adds every server to every app. Each laptop holds its own API keys, nobody sees who called what, and removing a tool means editing many config files. A gateway moves those jobs to one place:

Job	Without a gateway	With a gateway
Connecting	One config entry per server, per app, per person	One URL for everyone
Sign-in	Each server's own login or a pasted token	Your company login (SSO/OAuth) once, at the gateway
Which tools the model sees	Everything each server offers	An allow-list per team or per user
API keys and tokens	On each laptop, often in plain text	Stored on the gateway, never sent to the client
Logs	Scattered, or none	One audit log of every tool call
Rate limits	Whatever each upstream API does	Set per user, per tool or per server
Tool changes	A server can change a tool's description silently	The gateway can pin definitions and flag changes
Local (stdio) servers	Run on each laptop as you	Run once, on the gateway, ideally in a sandbox

To your AI app, the gateway is just another MCP server. It answers tools/list with the tools you allowed, and passes each tools/call on to the server that owns that tool.

Tool-definition pinning needs a word of explanation. A server can change a tool's name, description or input schema after you approved it, which is how a "rug pull" works. A gateway can store a hash of each definition and block or alert when it changes. It's the same check as pinning a server after you install it, done once for the whole team.

What the MCP spec says about gateways

The current spec (2026-07-28) has no "gateway" role. A gateway is a server to your clients and a client to your servers, so the rules for both apply. Four points matter most:

No token passthrough. The authorization spec says MCP servers "MUST validate that access tokens were issued specifically for them" and "MUST NOT accept or transit any other tokens." So a gateway checks the user's token, then uses its own credentials for each upstream server. It must not forward the user's token.
Per-client consent for OAuth proxies. The security best practices describe a "confused deputy" attack on proxies that use one static OAuth client ID upstream. Their rule: "MCP proxy servers MUST implement per-client consent", with exact redirect_uri matching and single-use state values.
Name clashes. The tools spec notes that "proxies that aggregate tools from multiple servers MAY encounter naming collisions" (two servers each with a search tool) and SHOULD fix it, for example by prefixing tool names with a server ID.
Per-user tool lists are allowed. The tool list "MUST NOT vary per-connection" but "MAY vary by the authorization presented on the request". A gateway that shows each user only their allowed tools is following the spec.

One more change helps gateways: the 2026-07-28 version dropped protocol-level sessions. Each request carries what it needs, so any gateway replica can handle any request. Check that the gateway you pick supports that version.

When you need an MCP gateway (and when you don't)

You probably need one if:

More than a handful of people use the same MCP servers.
Servers use shared company credentials (a database, a CRM, a cloud account) that you don't want on every laptop.
Security or compliance asks "who ran which tool, and when?"
You want to turn tools off for everyone in one step, for example after an advisory.
Agents run unattended (CI, scheduled jobs), so no human approves each call.

You probably don't if:

It's just you, with a few servers you've checked.
Every server is a remote one with its own proper OAuth, and you're happy managing access in each product.
You'd be adding a gateway only for the logo on a slide. A gateway you don't maintain is a new risk, not a control.

MCP gateway vs MCP proxy

People use the words loosely. A useful split:

An MCP proxy (or MCP proxy server) forwards traffic, usually to switch transport. For example, mcp-proxy describes itself as "a bridge between Streamable HTTP and stdio MCP transports", so a stdio-only app can reach a remote server or the other way round.
An MCP gateway is a proxy plus policy: one endpoint for many servers, sign-in, tool allow-lists, secrets, logs and limits.

Every gateway is a proxy. Not every proxy is a gateway. If a product only switches transports, don't count on it for access control.

How to choose the best MCP gateway for your team

There's no single best MCP gateway. Score each option against this table. "Must" items are the ones we'd refuse to skip for a team or enterprise setup.

Check	Why it matters	Priority
Sign-in with your identity provider (OAuth 2.1 / OIDC / SSO)	Access follows people when they join or leave	Must
Validates tokens for itself, no token passthrough	Required by the spec; stops stolen tokens being replayed upstream	Must
Tool allow-lists per user, team or role	Least privilege; fewer tools also means less context used	Must
Secrets stored server-side, injected per upstream	Keys never reach laptops or model context	Must
Audit log of every tool call (who, tool, arguments, result status)	Incident response and compliance	Must
Rate limits and timeouts per user and per tool	Stops loops and runaway agents	Must
Tool-definition pinning or change alerts	Catches rug pulls and silent tool changes	Should
Tool-name prefixing across servers	Avoids clashes, as the spec recommends	Should
Sandboxing for stdio servers it runs (containers, no host disk, egress limits)	The spec calls proxy-spawned stdio servers an escalation path	Should
Supports MCP 2026-07-28 (stateless requests)	Scales across replicas; older clients may need a fallback	Should
High availability, health checks	It's now on the path of every tool call	Should
Open source or a published security model, with an advisory history you can read	You can check what it does and how fast it fixes bugs	Should
Self-hosted or managed, and where logs live	Data residency and who can read your logs	Decide

Open-source and managed MCP gateways

All of these exist and are documented as of 2026-11-01. Facts come from each project's own page. This is not a ranking, and inclusion is not an endorsement.

Docker MCP Gateway (open source, MIT). A Docker CLI plugin (docker mcp) that runs each server in its own container, with per-server secrets and per-profile tool lists. We grade it B; see the Docker MCP Gateway guide and listing.
Microsoft MCP Gateway (open source, MIT). Described as a "reverse proxy and management layer for MCP servers". Runs on Kubernetes, has REST APIs to deploy and remove servers, and uses Microsoft Entra ID tokens with app roles for read and write access. Its README says the current version requires MCP 2026-07-28 clients.
IBM ContextForge (open source, Apache-2.0). "An open source registry and proxy that federates tools, agents, and APIs into one clean endpoint." Bundles chosen tools into "virtual servers", wraps REST and gRPC services as MCP, and has an admin UI and OpenTelemetry tracing.
agentgateway (open source, Apache-2.0, a Linux Foundation project). A proxy for agents and MCP servers with OAuth, JWT and API-key auth, role-based access rules written in CEL, and OpenTelemetry metrics and traces.
Cloudflare MCP server portals (managed, part of Cloudflare Access). A portal "centralizes multiple Model Context Protocol (MCP) servers onto a single HTTP endpoint". Access policies decide who sees which server, admins can hide tools or allow only a chosen list, and calls are logged. More in our Cloudflare MCP guide.
Amazon Bedrock AgentCore Gateway (managed, AWS). Turns APIs (OpenAPI, Smithy) and Lambda functions into MCP tools behind one endpoint, handles inbound and outbound auth, and offers semantic search over tools. Before wrapping every API as a tool, check when a plain API is the better choice.

Rough guide: if you already live in Docker, Kubernetes, Cloudflare or AWS, start with the option that fits that stack. Then run it through the checklist above, not the vendor's feature list.

If you'd like a second opinion on which gateway fits your stack, or help setting one up, tell us what you need to connect.

MCP gateway security: what a gateway can't fix

A gateway is a good control. It is also new software in the most sensitive spot in your setup. Plan for these:

Single point of failure. If it's down, every tool for every user is down. Run more than one instance and monitor it.
A juicy target. It holds every upstream credential and sees every call. A bug in the gateway exposes all of them at once. Patch it like a VPN or SSO server, keep its admin UI off the internet, and give it least-privilege credentials upstream.
Prompt injection still passes through. A gateway checks who calls which tool. It usually can't tell that a GitHub issue or web page told the model to do something harmful. Allow-lists and read-only tools shrink the damage; see MCP prompt injection.
Bad servers stay bad. A gateway doesn't make a server trustworthy. Check each one first with the 5-minute safety check and its grade in the directory.
Logs are sensitive. Tool arguments and results can contain customer data and secrets. Decide what to log, who can read it and how long to keep it.
Humans still approve writes. The spec says there "SHOULD always be a human in the loop with the ability to deny tool invocations." A gateway can require approval for risky tools, but it doesn't replace that.

Decision checklist

List your servers and users. Fewer than three people and a few checked servers? Skip the gateway for now and follow the MCP security best practices.
Pick sign-in first. The gateway should use your existing identity provider. See MCP authentication for how OAuth works in MCP.
Confirm no token passthrough. Users' tokens stop at the gateway; it uses its own credentials upstream.
Write the allow-lists. Start read-only. Add write tools per team, behind approval.
Move secrets to the gateway and delete them from laptops and config files.
Turn on audit logs, rate limits and timeouts before go-live, not after the first incident.
Pin tool definitions and alert on changes.
Sandbox any stdio servers the gateway runs, and limit their network access.
Point clients at the one URL. In Claude Code that's a single claude mcp add --transport http entry; see Claude Code MCP setup.
Plan for it failing: two instances, health checks, a patch routine.

Need a hardened MCP gateway set up for your team? We design and deploy MCP gateways with SSO, per-team tool allow-lists, server-side secrets, audit logs and pinned tool definitions, and we build the custom MCP servers behind them. Tell us what your team needs to connect.

Frequently asked questions

What is an MCP gateway?

A proxy that sits between AI apps (Claude, Cursor, VS Code, your own agents) and many MCP servers. Clients connect to one endpoint; the gateway handles sign-in, decides which tools each user sees, keeps credentials, logs calls and forwards each call to the right server.

Is an MCP gateway the same as an MCP proxy?

Not quite. An MCP proxy server forwards traffic, often just to switch between stdio and HTTP. A gateway adds policy on top: auth, allow-lists, secrets, logging and limits for many servers at once.

What is the best MCP gateway?

There isn't one best for everyone. Start with the one that fits your stack: Docker MCP Gateway if you use Docker, Microsoft MCP Gateway on Kubernetes with Entra ID, Cloudflare MCP server portals if you use Cloudflare Access, or AgentCore Gateway on AWS. Then check it against the must-haves in the checklist above.

What does an enterprise MCP gateway need?

Sign-in through your identity provider, no token passthrough, tool allow-lists per team or role, secrets kept on the gateway, an audit log of every tool call, rate limits and timeouts, and more than one instance with health checks. Also decide where the logs live and who can read them.

Is there an open-source MCP gateway?

Yes. Docker MCP Gateway (MIT), Microsoft MCP Gateway (MIT), IBM ContextForge (Apache-2.0) and agentgateway (Apache-2.0) are all open source. Check each one's security notes and advisory history before you deploy it.

Does an MCP gateway stop prompt injection?

No. It controls who can call which tool, which limits the damage, but it usually can't tell that text in a tool result is steering the model. Keep write tools behind human approval.

Does an MCP gateway make MCP servers safe?

No. It adds central controls around servers, but a server with a bug or bad intent is still a risk. Review each server and use the narrowest credentials it needs.

Do I need an MCP gateway for Claude Code?

Not for personal use. Claude Code connects to servers directly. A gateway helps when a team shares servers and credentials, because everyone adds one URL instead of many entries.

Does an MCP gateway add latency?

A little: one extra hop per call, plus any checks it runs. For most tool calls that's small next to the upstream API and the model's own time.