What is an MCP gateway?
An MCP gateway is a server that sits between your AI application and the MCP servers you already run. It speaks MCP on both sides: a client to your real servers, a server to your app. It merges their tools into a single catalog and adds routing, authentication, policy enforcement, observability and lifecycle management on the way through.
That is the whole category. Everything else on the market is a variation in where the gateway runs, how policy is expressed, and how much of the catalog it hides from the model. The pitch is consistent across vendors too: wire many servers into a client directly and you get tool-catalog bloat in the model's context, credentials scattered across every server definition, no central record of what was called, and as many points of failure as you have servers. A gateway collapses that into one address.
Gateway, agent gateway, or MCP proxy: what is actually different
These three phrases get used interchangeably in product copy, and they are not the same thing.
An MCP proxy does protocol mediation. The classic job is making a local stdio server reachable by a remote client - the proxy wraps the transport and forwards bytes along without interpreting the payload. It does not know what a tool is. It cannot merge two servers, because merging requires reading the tool list.
A gateway interprets. Because it speaks MCP in both directions it can read every upstream catalog, decide which server a given call belongs to, enforce a rule before forwarding it, and write an audit row afterwards. That is a control plane, not plumbing.
Agent gateway is usually a gateway sold to a different buyer - the same routing layer positioned for a fleet of agents rather than a fleet of MCP servers. Worth reading the docs rather than the noun. If you are still deciding what sits on the client side of any of this, what an MCP client is and why the one you pick matters covers that half.
The four routing shapes, compared
Fronting your MCP servers is not a binary choice, and the interesting option is the one no gateway vendor puts on the list.
| Shape | What it actually does | What it solves | What it does not solve | When it is the right call |
|---|---|---|---|---|
| Direct wiring | Each MCP server is configured in the client individually; every tool from every server lands in the model's context | Nothing to operate, nothing to debug in the middle, no extra hop | Catalog size, scattered credentials, no shared audit trail, one failure per server | A handful of servers, one team, one machine, low compliance surface |
| Thin proxy | Forwards or wraps a connection at the transport layer; does not read the payload | Reachability - a local stdio server becomes usable by a remote client | Nothing about the catalog, policy, or the number of servers you run | You need remote access to a server that was written to run locally |
| Gateway | Speaks MCP both ways, merges catalogs, routes calls, enforces auth and policy, records what was called | Central credentials, one audit trail, one address, catalog control across many servers and teams | It does not reduce how many servers exist, and it cannot join records that live in different systems | Many servers, multiple teams, per-tenant isolation, an audit requirement |
| One server over a shared spine | A single MCP server exposes a data model that is already joined underneath, in one schema | The cross-system question - the join happens in the database, before the model ever sees it | Systems you have deliberately kept separate and do not want joined; it is a data-model change, not a routing change | The questions you actually ask span systems that never agreed with each other |
The question page one does not ask
Search for "mcp gateway" and every result on the first page is published by a company that sells one. That is not a scandal, but it does shape the framing: each page treats routing as the only decision, because routing is the product each page is selling.
The prior question is which problem you have. A gateway makes N servers manageable. It does not reduce N, and it does not change what is behind them. Those are different failure modes and they feel identical from the client side, because both of them show up as an agent that cannot answer your question.
The tell is in the question itself. "List the open issues in this repo" is a routing problem - one server owns the answer, and the gateway's job is to get the call there cleanly. "Which paying customers asked for the feature we are building, and what do they pay?" is not a routing problem. No single server owns that answer. The billing system knows the money, the feedback tool knows the request, the tracker knows the work, and none of them share a customer record. Route that question perfectly to all three and the agent still has to reconcile three partial answers itself, which is exactly the step that goes wrong.
The scale of the mismatch is easy to underestimate: the average company runs 101 SaaS apps, and roughly $21M a year goes to licenses nobody uses (Okta and Zylo). Access to all of them was never the constraint. We have written separately on why the number of servers is the wrong thing to count, and on what a server exposes rather than how you reach it - the short version is that a catalog of well-designed tools over siloed data is still siloed data.
When a gateway is the right answer
There are three situations where a gateway is straightforwardly the correct call, and it is worth being specific rather than gracious.
Many servers across many teams. Once separate teams are each running their own MCP servers against their own systems, the operational problem is real and it is not going away by fixing anyone's data model. Somebody has to own version drift, health, and which servers a given client is allowed to see. That is a gateway's job.
Per-tenant access isolation. If different users, customers, or agents must reach different subsets of the same servers, the enforcement point has to sit outside the individual servers. Pushing that rule into every server means reimplementing it everywhere and getting it wrong somewhere.
Compliance and audit requirements. If you need to prove which agent called which tool with which arguments on which date, you need one place where every call passes through. Directly wired clients produce that record nowhere. A gateway produces it by construction, which is often the entire reason it gets bought.
If any of those three describe you, buy or build the gateway. It will do what it says.
Something you can check in a minute
The claim above is checkable, which is the only reason it is worth making. Connect an MCP client to the hosted endpoint at https://platform.aioproductos.com/api/mcp - Streamable HTTP, OAuth 2.1 with PKCE, Dynamic Client Registration supported - or run npx -y @aioproductoscom/mcp@latest with no token, which starts in demo mode against a fully seeded showcase workspace with a read-only subset of the tools. Nothing to paste, nothing to cancel. Then ask it the cross-system question: which paying customers asked for the feature I am building, and what do they pay?
Across a gateway fronting a billing MCP, a feedback MCP and a tracker MCP, that is three calls and a reconciliation you perform yourself. Against the product management MCP, it is one query against one customer record, because revenue, feedback, work and code sit in one schema underneath. The full surface is 71 tools that read and act, with writes landing in human review, plus three interactive ui:// MCP Apps - one of them a live board where changing a status writes back through update_task.
The decision, stated plainly
Count the questions you actually want an agent to answer, not the servers you happen to run. If those questions each live inside one system, a gateway is the right layer and the shape of your data is fine. If they span systems that were never designed to agree, routing is the wrong lever, and adding a control plane in front of the disagreement will not resolve it.
Most teams need both eventually. Very few need the gateway first.
If you want to see what a joined record does to those questions before changing anything about how you route, the MCP guides hub covers what the single-tool MCPs expose and where each one stops.