What is an MCP gateway, and do you need one?

01What is an MCP gateway?

The Model Context Protocol connects a client, such as a coding agent or a chat app, to servers that offer tools, resources and prompts. Without a gateway, every client is configured with every server separately, each server is launched however its README says, and each one holds its own credentials. An MCP gateway changes the shape: the client is configured with one server, the gateway, and the gateway connects onward to the real servers, presenting their tools as one combined list.

That position is why gateways exist. Every tool list and every tools/call passes through one process, so it is the natural place to decide which tools a client may see, which calls are allowed, which credentials to attach, and what to record. One example is Docker's MCP Gateway: its documentation describes a proxy between AI clients and MCP servers that manages configuration, credentials and access control, and its source is MIT licensed.

02MCP gateway vs proxy: is there a difference?

The words are used loosely, so it is safer to compare by function. The MCP security best practices define an MCP proxy server narrowly: an MCP server that connects MCP clients to a third-party API and acts as a single OAuth client to that API. A gateway, in common use, is a proxy that aggregates many MCP servers behind one endpoint and adds policy on top.

Some gateways only relay traffic to servers that run elsewhere. Others also launch and manage the servers. Docker's gateway is in the second group: it runs servers in containers, starting each one on demand when a tool is requested. Whether a product is called a gateway, a proxy or a hub matters less than two questions: what does it decide on each call, and where do the servers' processes run?

03What an MCP gateway does: authentication, routing, allow-lists and audit

Authentication has two sides. Toward the client, a gateway served over HTTP should demand a credential, since anything that can reach it can call every tool behind it. Toward upstream APIs, the gateway holds the credentials so the client and model never do. The MCP security best practices are strict here: token passthrough, where a server accepts a client's token and forwards it downstream, is forbidden, and servers must not accept tokens that were not issued for them. Proxies that use one static OAuth client ID must collect per-client consent, or they create a confused deputy. And a session ID must never be used as authentication.

Routing and allow-lists come next. A gateway can expose only the tools a team approved, by exact name, and refuse the rest, so a new tool on a server does not appear in every client automatically. It can also check arguments against the tool's schema before forwarding, and check results against an output schema before the model reads them.

Audit is the third job. The MCP tools specification says clients should log tool usage for audit purposes and show tool inputs to the user before calling the server. A gateway records every decision in one place, including calls it refused and tools it withheld, which is far easier to review than logs scattered across clients.

• Require a credential on the gateway's own endpoint, and bind it to loopback unless you mean otherwise.
• Keep upstream credentials in the gateway; never pass a client's token through.
• Expose an explicit tool allow-list, by exact name.
• Validate arguments and results against the tool's schemas.
• Log every decision with the server, tool and policy that decided it.

04What a gateway does not do: isolate the server process

A relay-only gateway decides what goes over the protocol. It has no say over what a local server does as a program. The MCP security best practices describe local MCP server compromise: a server downloaded and run on your machine executes with the client's privileges, so a malicious payload can read files, exfiltrate data or delete them. Their mitigation is a sandbox: execute server commands in a sandboxed environment with minimal default privileges, and restrict file system and network access.

Gateways that launch servers can add that boundary. Docker's documentation says its gateway runs MCP servers in isolated containers with restricted privileges, network access and resource usage. How strong the boundary is depends on the isolation technology underneath, a shared-kernel container or a virtual machine, so it is worth checking.

The gateway itself is also a target. The best practices warn that a proxy which spawns stdio servers turns a stolen proxy token into arbitrary command execution, and recommend restricting, logging and sandboxing what it spawns. And no gateway makes tool output trustworthy: a result that matches its schema can still carry text written to steer the model.

05Do you need an MCP gateway?

For one developer with one or two well-known servers, a careful client configuration may be enough. A gateway starts to pay off when several people or agents share many servers, when security needs one place to set policy, or when someone will ask for an audit of what tools were called. That is the usual shape of MCP security in an enterprise.

When you evaluate one, ask where each server's process runs and what it can reach, not only what the dashboard shows. A gateway in front plus a sandbox per server behind it covers both halves: the protocol and the program.

• Do several clients or teams share the same MCP servers?
• Do you need one tool allow-list and one audit trail of MCP calls?
• Are third-party servers started with npx or pip on developer machines?
• Must upstream credentials stay out of clients and models?
• Does each server get only the files and network hosts it needs?