MCP gateway: what it solves, and what it hides

An MCP gateway is a proxy that sits in front of several Model Context Protocol servers and presents them to a client as one endpoint. Instead of configuring twelve servers in your agent, you configure the gateway, and it handles discovery, routing, credentials and often lifecycle, starting a server when a tool on it is first called.

Four open implementations give a sense of the range. IBM’s ContextForge (Apache 2.0, published as mcp-contextforge-gateway) is a registry and proxy federating MCP, A2A and REST or gRPC endpoints behind one interface. Docker’s MCP Gateway ships as a docker mcp gateway CLI plugin and leans on the container toolchain for isolation and lifecycle. Microsoft’s MCP Gateway is a reverse proxy for session-aware, stateful routing of MCP servers on Kubernetes. Bifrost (Apache 2.0, Go, from Maxim AI) is primarily an LLM gateway that also acts as an MCP client: it connects to configured servers over stdio, HTTP or SSE, and can re-expose a chosen subset of their tools on its own /mcp endpoint. Governance, packaging, routing and tool access respectively: the label covers quite different products.

“MCP proxy” usually describes the same shape with a narrower job: forwarding to one server, frequently to bridge transports, such as exposing a stdio server over HTTP so something remote can reach it. A gateway is a proxy that also aggregates, authenticates and governs.

The operational case for both is strong at team scale. Both also change what a client can observe about the servers behind them. What a gateway solves and what it hides are below.

What problem does an MCP gateway solve?

Four, mostly at organisational scale rather than on a laptop.

Configuration sprawl. Every client that needs a set of tools has to be configured with every server in that set. Ten clients and twelve servers is a hundred and twenty pieces of configuration that drift. A gateway makes it ten.

Credential handling. Without a gateway, every developer machine that runs a packaged server holds the credentials that server needs. A gateway can hold them centrally and inject them at call time, so the token for your production database is not sitting in a dotfile on fifteen laptops.

Governance and observability. One place to see which tools were called, by whom, how often, and one place to deny a tool outright. Getting that per-client is impractical.

Transport and lifecycle. Bridging stdio servers to HTTP, starting containers on demand, and keeping a warm pool are all jobs a client should not be doing.

As a rough threshold: a gateway starts paying for itself once the number of clients multiplied by the number of shared servers exceeds what one person can keep correct by hand, which in practice is somewhere around five clients and five servers, or the first time a shared server needs a credential you are not willing to copy onto every laptop. Below that it is a moving part you are maintaining for its own sake. The question above that line is what it costs.

What does a gateway hide?

Per-server provenance, from the client’s point of view. Before the gateway, your agent connects to twelve servers, and each is a thing you chose, with its own publisher, its own version, and its own supply-chain history. After the gateway, your agent connects to one endpoint that offers ninety tools. The tools no longer carry visible parentage. Whoever administers the gateway decides what is behind them, and adding a thirteenth server is a change your client cannot observe.

That is a legitimate design, and it is a real transfer of trust. You are no longer trusting twelve publishers. You are trusting one operator’s judgement about twelve publishers, continuously, including for servers added after you connected.

Blast radius. A gateway that holds credentials for every server behind it, and can start processes, is the highest-value target in the deployment. Compromise a single MCP server and you get that server’s access. Compromise the gateway and you get all of it, plus a trusted position from which to serve modified tool definitions to every client. The same centralisation that fixes credential sprawl creates a single point worth attacking.

Tool-definition integrity. The gateway rewrites what the client sees: names get prefixed, descriptions get merged, schemas get normalised. A model decides which tool to call based on that text. Anything sitting in the path able to alter tool descriptions is in a position to influence model behaviour, which is the mechanism behind tool poisoning. The trust boundary moves outward to include the gateway.

How does a gateway affect a trust score?

Directly, because it changes the subject of the measurement.

We score what we can observe. A remote component is an endpoint we probe: we check its transport, TLS, HSTS, DNSSEC, authentication behaviour, declared protocol version and schema quality. Point us at a gateway and we score the gateway, correctly and honestly, as a single remote endpoint. We cannot see the twelve servers behind it, so nothing about their provenance reaches the score.

The result is a score that is accurate and narrower than it looks. A gateway with excellent TLS, proper RFC 9728 authentication and a current protocol version can score well while proxying servers that would each score poorly. Nothing has been faked. The measurement simply has a different subject than a reader might assume.

This is the same structural limit that makes authentication-gated endpoints hard to assess. On 18 August 2026, 1,487 of 12,682 remote components declared a required secret header in their registry entry, and the genuinely auth-gated population is larger than that, because an endpoint can demand OAuth without declaring a header. Either way, what we can establish from outside is bounded. A gateway adds a second layer of the same problem, by design.

When should you not use one?

• Solo development. A gateway adds a moving part, a process to keep running and a config to keep correct, in exchange for solving a sprawl problem you do not have with three servers.
• When you need per-server auditability. If you have to be able to say which publisher’s code handled a particular request, keep the servers distinct at the client.
• When it would become the only thing holding your credentials. Centralising secrets is a real benefit and a real concentration. It is worth it when the gateway is operated with the care a secrets store deserves, and not otherwise.
• When the servers behind it are not ones you would install individually. Aggregation changes your view of a server’s provenance, not the provenance itself. If you would not run a server directly, routing it through a gateway has not addressed the reason.

Where to go next

• Running remote endpoints well: remote MCP server security covers the signals we check on any endpoint, gateway included, and authentication covers doing OAuth properly.
• Understanding the tool-description risk: MCP vs API explains why text a model reads is part of your attack surface.
• Evaluating what is actually behind an endpoint: point the MCP Inspector at it and read the tool list yourself.

A gateway answers configuration sprawl and credential handling across a team. It does not answer “are these servers trustworthy”, and it makes that question harder to answer from the client side, since the per-server evidence now sits behind the endpoint. Assessing the servers first, then deploying the gateway, keeps both answers available.