What Is an MCP Gateway? A Plain-English Explanation

An MCP gateway is a single endpoint that sits between AI clients and one or more MCP servers. It authenticates each caller, decides which tools that caller can see and use, forwards requests to the right server, and logs the result. You configure clients once, against the gateway, instead of configuring every server everywhere.

Why the gateway pattern exists

The Model Context Protocol lets an AI client discover tools at runtime and call them. In the simplest setup, that means a local process: the client launches a server over stdio and talks to it directly. That is fine for one developer on one laptop.

It stops being fine as soon as the situation grows. Ten people want the same CRM tool. A cloud assistant needs to reach a server that lives on your network. A credential for a billing system must not be copied into ten config files. Each of those problems is the same shape: many clients, many servers, shared secrets, and no central place to apply rules.

A gateway is the central place. Two independent open source projects describe it in very similar terms. Docker’s MCP Gateway is described in its documentation as a proxy that sits between AI clients and MCP servers and centralises configuration, credentials and access control. Microsoft’s mcp-gateway repository calls itself a reverse proxy and management layer for MCP servers, with routing, authorization and lifecycle management on Kubernetes.

What a gateway typically does

Different products emphasise different jobs, but the core list is short.

1. Terminate the connection. The gateway exposes one HTTPS endpoint using a transport such as streamable HTTP, so remote clients can connect without a local process.
2. Authenticate the caller. Usually a Bearer token, an API key or OAuth, so each caller has its own identity.
3. Filter the catalogue. The caller sees only the tools it is allowed to see. Our article on tool allowlists goes deeper.
4. Route the request. The call goes to the right upstream server, which the gateway may start on demand, as Docker’s does with containers.
5. Hold the credentials. Upstream API keys stay on the gateway side and are never handed to the model or the client.
6. Record the call. Caller, tool, arguments and outcome go to a log, which is the subject of MCP audit logging.

Key takeaway: a gateway is a control point, not a feature. Its value is that rules, secrets and logs live in one place you can inspect, instead of being scattered across every client.

Three shapes you will meet

Not every “gateway” is the same kind of thing, and the differences matter when you compare them.

Shape	What it is	Who runs it	Example
Local proxy	Runs beside the client, starts servers on demand, adds credentials	The user or developer	Docker’s MCP Gateway, per its documentation
Self-hosted service	A reverse proxy and control plane deployed on your infrastructure	Your platform team	Microsoft’s Kubernetes-based project
Hosted endpoint	A managed HTTPS endpoint that exposes connected data sources as tools	The vendor	BusinessMCP’s hosted MCP endpoint

The hosted shape is the least work. BusinessMCP’s managed MCP hosting page describes an endpoint at /api/mcp authenticated with a Bearer key, with no container to run and no tunnel to keep open. The trade-off, which that page states itself, is that it hosts your business data connections, not your own MCP server code. If you need to run arbitrary custom servers, a self-hosted gateway is a better fit. We compare the two routes in self-hosted versus managed gateways.

Gateway tools versus gateway software

People use “MCP gateway tools” for two things at once, and it is worth keeping them apart. The software is the proxy. The tools are the callable functions an agent ends up with. A gateway can be well built and still expose far too many tools, with write and send permissions on by default.

That is why a published catalogue matters. BusinessMCP’s page listing every tool its MCP endpoint exposes is generated from its live registry and says which tools are scoped by API key, which are gated by plan, and which wait for owner approval before acting. Whatever gateway you choose, ask for an equivalent list.

When you do not need one

Be sceptical of the idea that every MCP setup needs a gateway. You can skip it if:

• one person uses one or two local servers on their own machine;
• the servers touch nothing sensitive;
• nobody else needs the same tools.

BusinessMCP’s own remote versus local MCP guide makes the same point: local servers suit personal developer tools and data that should stay on one machine, while remote servers suit team sharing and cross-assistant access. The two can coexist in the same client.

What a gateway does not fix

A gateway enforces rules on tool calls. It does not read intent. If a model is tricked by text inside a web page or a ticket into calling an allowed tool with harmful arguments, the gateway will see a legitimate-looking call. Mitigation therefore depends on keeping the allowed set small and gating side effects, as we cover in MCP gateway security.

It also does not vet upstream servers. A gateway that fronts someone else’s server is trusting that server’s tool descriptions. The Model Context Protocol security guidance and the OWASP material on LLM applications both treat that as a distinct risk.

A request, step by step

It helps to follow one call through a gateway to see where each control applies. Suppose an assistant wants to read this week’s search performance for a website.

1. The client sends a tools/list request to the gateway endpoint with its key. The gateway identifies the key, finds the policy attached to it and returns only the tools that policy allows. A reporting key might see a handful of read tools and nothing that sends or deletes.
2. The model picks a tool and the client sends tools/call with arguments.
3. The gateway checks the call against the policy again, because discovery filtering alone is not enforcement. A tool the caller never saw must also be refused if it is called by name.
4. If the tool needs an upstream credential, the gateway attaches it on its own side. The model never sees the token.
5. The upstream server answers. The gateway may redact fields the key is not allowed to see, then returns the result.
6. Whatever happened, the gateway writes a log line.

Steps 3 and 5 are where weaker designs cut corners. Hiding a tool from a list is cosmetic if the call itself is not checked. BusinessMCP’s description of its hosted endpoint says restricted keys both advertise fewer tools and have their output redacted, which is the two-sided behaviour to look for in any product.

Questions worth asking a vendor or project

Because the term is loose, marketing pages can make very different products sound identical. A few direct questions cut through it:

• Does it run servers, proxy existing ones, or host connections to data sources?
• Which transports does it speak toward clients and toward upstream servers?
• Where do upstream credentials live, and can an operator read them back?
• Is the tool catalogue documented, and can you restrict it per caller?
• What is logged, for how long, and can you export it?
• What is the licence, and is the code open for inspection?

None of these needs a demo to answer. If the documentation cannot answer them, treat that as information.

A short way to decide

Ask three questions. How many people and assistants will share this? Do any of the tools touch credentials, money or customer data? Do you need to prove later what an agent did? Two or three yes answers mean a gateway is worth the effort. From there, the evaluation checklist turns the decision into concrete tests.