“Gateway,” “proxy,” and “router” get used almost interchangeably when people talk about putting something in front of their Model Context Protocol servers. They are not the same thing, and the difference is not cosmetic — it decides which questions your infrastructure can answer when an agent misbehaves, an auditor asks, or a second team wants in. This page draws the line between the three, then gives you a way to decide which one your situation actually calls for. It is deliberately vendor-neutral: the goal is to help you pick the lightest layer that does the job, which is sometimes not a gateway at all.
Three shapes on one line of traffic
All three sit on the same wire — between an agent (the MCP client) and one or more MCP servers (the tools). What separates them is how much they understand about the traffic they carry, and how much they are allowed to decide.
- A proxy passes traffic through. It is a transport adapter: it moves bytes between a client and a server, typically bridging a local
stdioserver to a network transport (HTTP, SSE, WebSocket), terminating TLS, and crossing a network boundary. In the words of one analysis, a proxy “forwards bytes and does not interpret them.” It solves a connectivity problem — reaching a server you otherwise couldn’t — and adds close to no latency. It does not, on its own, decide whether a call should happen. - A router sends traffic to the right place. It reads far enough into each request to know which tool is being called, keeps a registry of connected servers, and dispatches to the correct upstream. Crucially, it also solves discovery: a client connects to one place and asks “what tools are available?” instead of knowing where each server lives. A router understands capability, but — as commonly defined — it “does not gate by policy” and has no notion of who the caller is.
- A gateway governs traffic. It does everything a router does, and adds a control plane on top: identity, per-tool authorization, rate limits, approvals, audit, cost attribution, and lifecycle management of the servers behind it. A useful one-line test, from Permit’s write-up, is that a gateway decides “who the agent is, on whose behalf it is acting, what it may do, and how that decision is recorded.” A proxy solves a packet-path problem; a gateway solves a trust-decision problem.
The layers nest. A router usually contains proxy behavior (it still has to bridge transports); a gateway usually contains a router (it still has to dispatch). So this is less three rival products than three points on a line of increasing responsibility — and increasing weight.
What each one actually does
The clearest way to tell them apart is by capability. This table follows the distinctions drawn by TrueFoundry and Permit; the checks mark what each layer is expected to do by definition, not what any specific product ships.
| Capability | Proxy | Router | Gateway |
|---|---|---|---|
| Transport bridging (stdio ↔ HTTP/SSE/WS), TLS | Yes | Yes | Yes |
| Cross network boundaries | Yes | Yes | Yes |
| Tool discovery / aggregate registry | No | Yes | Yes |
| Route by capability to the right upstream | No | Yes | Yes |
| Identity & delegated-authority binding | No | No | Yes |
| Per-tool / per-argument authorization | No | No | Yes |
| Human approval in the loop | No | No | Yes |
| Rate limits & cost attribution | No | No | Yes |
| Audit log tied to an identity | Path only | Partial | Yes |
| Latency added | Lowest | Low | Highest |
| Operational weight | Lowest | Low | Highest |
Read the last two rows as the price of the ones above them. Every capability a gateway adds is code on the hot path and a component you now have to run, secure, and keep available. That cost is the whole reason this article exists: you want the smallest layer that answers the questions you will actually be asked.
A decision framework
Match the layer to the blast radius and the accountability you need, not to the size of your ambitions. A rough progression, drawn from the same sources and widely echoed in 2026 write-ups:
- A proxy is enough when you are one developer (or a tight, trusted group) connecting local tools across a network boundary — WSL to Docker, a laptop to a remote host, a
stdioserver exposed over HTTP for a single client. Actions are low-risk and reversible, there is no one to attribute a call to but you, and “who did this?” has an obvious answer. Reaching the server is the whole problem. - A router is enough when a small team runs a handful of trusted internal servers and the pain is discovery and fan-out, not governance. You want one endpoint that aggregates many servers and dispatches correctly; you are not yet enforcing who may call what. Several analyses call this the typical “v1” for most teams — and it is a perfectly good place to stop if the actions stay internal and reversible.
- A gateway earns its weight when agents act on behalf of people against real systems — customer data, production databases, SaaS accounts, anything with money or privacy attached — or when you are subject to compliance, or when more than a handful of developers and agents share the same tools. The signal is simple: if a bad call would trigger a request for identity proof, consent evidence, authorization logic, or an audit record, you needed a gateway before the incident, not after it.
One transition is worth naming because it catches teams off guard. Moving from a router to a gateway is the hard one. A router gets you shipping fast, but it cannot answer identity-correlated questions after the fact — “which person’s agent deleted that record, and was it allowed to?” — and that gap tends to surface during a security review or an incident, exactly when a rebuild is most expensive. If you can already see regulated data or on-behalf-of action on the horizon, it is cheaper to reach for governance before the router calcifies into a dependency.
The honest case for staying light
A gateway is the heaviest option, and heaviest is not a synonym for best. It adds a hop, a dependency, and a component that — if it goes down or misconfigures — can take your agents’ entire tool access with it. Mature gateways answer this with stateless, horizontally-scaled data planes and graceful degradation, but you are still choosing to run more infrastructure. For a solo experiment, a demo, or an internal script that only ever touches a sandbox, a proxy or a router is not a compromise — it is the correct, proportionate choice, and adding a control plane would be over-engineering.
The reason “gateway” dominates the conversation anyway is that the term has become a catch-all: many products branded “MCP gateway” also aggregate, discover, and federate, so the router’s job is folded inside. IBM’s open-source ContextForge, for instance, presents itself as a single control plane that federates MCP, REST, and agent protocols with centralized discovery and observability — router-and-gateway in one binary. That is fine, as long as you buy the governance because you need governance, not because the box on the diagram said “gateway.”
How to choose, in one pass
Ask three questions, in order, and stop at the first “yes”:
- Do agents act on behalf of humans against systems that matter — or are you under compliance? If yes, you want a gateway: identity, per-call authorization, approvals, and an audit trail tied to a name.
- Do you have several servers and want one endpoint with unified discovery, but the actions stay internal and reversible? If yes, a router covers you — and you can graduate to a gateway later, ideally sooner than the router becomes load-bearing.
- Are you one person (or a trusted few) just trying to reach a local server across a boundary? If yes, a proxy is the right amount of machinery. Add nothing.
The framework is deliberately biased toward the lightest tool that answers your real questions. “Gateway” wins only when the questions are about trust and evidence, not just connectivity.
Where Meandr fits
For full disclosure: Meandr is an MCP gateway, so it sits at the heaviest end of this line by design — one endpoint that aggregates a project’s servers into a single filtered tools/list, routes each call to the right upstream, and adds the control plane on top: allow, deny, or require a human’s approval per call, rate limits, an audit record, and upstream authentication it signs in for you. If your situation lands on “proxy” or “router” above, you do not need it yet, and this page is not trying to talk you into it. If you land on “gateway,” start with what an MCP gateway is and then the Meandr gateway itself.
Sources
- TrueFoundry — MCP Gateway vs. MCP Proxy vs. MCP Router: Architecture and Decision Framework
- Permit.io — MCP Gateway vs MCP Proxy: What’s the Difference, and Why It Matters in Production
- IBM — ContextForge AI Gateway (open-source MCP gateway and registry)
- Model Context Protocol — specification and documentation