What Is an MCP Gateway (and Do You Need One)?
One endpoint for every MCP server sounds tidy — until you count the tools it dumps into your context window.
An MCP gateway is a proxy that sits between your client and many MCP servers, exposing them all through one endpoint with shared authentication, logging, and routing. Instead of your editor connecting to eight separate servers, it connects to the gateway, and the gateway fans requests out to the real ones. That's the whole idea. The harder question — the one this article answers — is whether you actually need one, because for most solo developers the answer is no.
If you're still fuzzy on the layer below this, read what is an MCP server first; a gateway only makes sense once you're running several servers at once.
What an MCP gateway actually does
An MCP gateway does three concrete jobs: it aggregates multiple servers into one connection, it centralizes auth and secrets, and it gives you a single place to log and rate-limit tool calls. Your client sees one server; the gateway holds the map of what's behind it.
The reason this matters is transport. About 90% of MCP servers run locally over stdio — a subprocess talking to your client over stdin/stdout on the same machine. That's fine for one laptop, but stdio doesn't cross a network. A gateway typically speaks stdio (or Streamable HTTP) to your client and then re-exposes the fleet remotely, so a whole team can hit the same set of tools. See local vs remote MCP for why that transport line is the real fork in the road.
A few things a gateway is not: it is not an MCP server itself in the useful sense (it has no tools of its own), and it does not make a badly-scoped server good. Garbage in, garbage out — with a shared log.
When you don't need one (most of the time)
Skip the gateway if you're one developer running a handful of local servers. Your client already manages multiple stdio servers natively — that's what the mcpServers block in your config is for. Adding a proxy in front buys you nothing but a second process to crash.
Concretely, you don't need a gateway to run Filesystem, the official reference server for scoped local read/write, alongside the GitHub MCP Server and Context7 for version-specific library docs. Three entries in one config file, all stdio, done. Adding these is a five-minute job — see how to add an MCP server.
The trap is thinking a gateway reduces complexity here. It relocates it. You still configure every downstream server; now you also configure the gateway, its transport, and its auth. For a personal setup that's a worse trade.
When a gateway earns its place
Reach for a gateway when the problem is organizational, not personal. Three signals mean it's time:
- A team shares tools. You want ten engineers hitting the same GitHub, Jira, and internal-DB servers without ten copies of the credentials. The gateway holds one set of secrets and hands out access.
- You need an audit trail. Compliance or security wants every tool call logged in one place with who called it. A gateway is the natural choke point; scattered stdio subprocesses are not.
- You're going remote anyway. If servers must live behind a network boundary — in a cluster, behind SSO — you need something that terminates auth and speaks HTTP. That's a gateway whether you call it one or not.
Notice the common thread: every case is about many people or many machines, never about making one dev's setup nicer.
The cost nobody mentions: your tool budget
The real risk of a gateway is that it makes it trivial to over-expose tools, and tools are not free. Every tool definition from every downstream server gets loaded into the model's context on each request. Practical clients start degrading somewhere around a 40-tool budget — Cursor, for instance, historically capped at 40 active tools, and even without a hard cap, model accuracy drops as the list grows.
Aggregate five servers with ten tools each and you've blown that budget from one config line. The model now picks from fifty options, hesitates, and calls the wrong one. A gateway makes this failure mode one connection away.
So the gateway's most valuable feature is not aggregation — it's the ability to filter. A good gateway lets you allow-list which tools pass through, per client. If your gateway can't do that, it's a liability at scale. For the underlying math, see Cursor tool limit math.
| No gateway | With gateway | |
|---|---|---|
| Best for | 1 dev, local stdio servers | Teams, remote/shared servers |
| Auth | Per-server, in local config | Centralized, one credential store |
| Logging | Per-server, scattered | One audit trail |
| Tool budget | You control it directly | Easy to blow past 40 |
| Failure surface | Each server | Server plus the gateway |
| Setup cost | Low | Higher, ongoing |
How to add one without regret
If you do deploy a gateway, treat it as infrastructure and lock down what flows through it. The minimal shape from your client's side is just another server entry — the gateway is the one endpoint; the complexity lives on its far side:
{
"mcpServers": {
"gateway": {
"command": "npx",
"args": ["-y", "my-mcp-gateway", "--config", "./gateway.json"]
}
}
}
Then do the unglamorous work: prefer official servers over community forks for anything touching credentials (the GitHub MCP Server is official; many GitHub proxies are not), allow-list tools per client to protect the budget, and confirm the gateway logs before you trust it as your audit trail. Security posture doesn't improve just because there's a proxy — read MCP security: what actually matters before you point a shared gateway at production.
When something breaks — and with an extra hop, it will — the troubleshooting guide covers the usual suspects: transport mismatches, a downstream server the gateway can't reach, and the silent tool-budget overflow.
Still deciding? Browse the best MCP servers first and count how many you'd genuinely run at once. If it's three, you don't need a gateway. If it's fifteen across a team, you do.