What an MCP gateway does, what it does not, and when you need one

An MCP gateway centralises the things you do not want implemented separately in every server: who may call which tool, rate limits, credentials and the audit trail. Here is what it does, what it cannot do, and the threshold where it stops being overhead.

An MCP gateway sits between your agents and your MCP servers. Every call passes through it, and it handles the things you do not want written separately into each server.

That is the whole idea. The useful part is knowing when it earns its cost, and being honest about what it does not solve.

What it actually does

Five things, and the fifth is the one people skip.

Authenticating the caller, so a server does not have to.

Deciding which agent may use which tool, in one place rather than five.

Rate limiting, because a model in a loop will call a tool far more often than a person ever would.

Holding the credentials, so the servers themselves do not carry secrets.

Writing the audit trail: which agent called which tool, with what arguments, on whose behalf, and what came back.

How it differs from an API gateway

The mechanics are similar. The unit of control is not.

An API gateway governs endpoints and methods, and the caller is code following a fixed path. An MCP gateway governs tools and the arguments they are invoked with, and the caller is a model deciding what to try. That difference is the reason an API gateway's logs are not sufficient: knowing a request was allowed tells you less than knowing which tool an agent chose and what it passed in.

What it does not do

This is the part worth being blunt about, because gateway vendors are not going to lead with it.

A gateway controls who may call a tool. It does not control what the tool exposes once called. A server wired to a database connection with broad read rights has granted broad read rights to every caller the gateway permits. The gateway is the second control. Narrow servers scoped to one capability are the first, and nothing in the gateway layer substitutes for them.

It also does not make answers correct. An agent allowed through to raw tables will answer confidently about a metric it has no definition for. That is what the semantic layer is for, and the two problems are routinely confused because both get described as governance.

When you need one

Not at one or two servers. A well-scoped server handles its own authentication and logging, and a gateway in front of two of them is a component to maintain for little return.

The threshold is when the same policy lives in more than two places. That is the point at which versions drift, and the question "which agent can reach what" stops having a single answer. A practical test: if you cannot name every tool every agent can call without reading code, you are past it.

The second trigger is organisational rather than technical. Once more than one team is building servers, a gateway is how you stop each team inventing its own permission model, which is a far more expensive problem to unpick later than to prevent now.

What a security review will ask

The same three things it asks about any MCP deployment, and a gateway makes two of them easier to answer.

What can each agent reach, which the gateway can answer in one place. What is recorded, which the gateway owns. And what the servers themselves expose, which the gateway cannot answer at all, and which is why the server design still gets reviewed on its own. More detail on that in what a security review needs from you.

Build or buy

A thin internal gateway in front of a handful of servers is a sensible week of work and keeps the policy in code you own. Governing dozens across several teams starts to look like running a product, and the case for buying strengthens.

The failure mode is building one and not staffing it. An unmaintained gateway is worse than none, because it looks like a control and is not one.

Frequently asked questions

What is an MCP gateway?

A single point every agent call passes through on its way to your MCP servers. It handles the things you do not want written separately into each server: authenticating the caller, deciding which agent may use which tool, applying rate limits, holding the credentials so the servers do not, and writing the audit trail. Without one, each server implements its own version of all five and they drift.

How is an MCP gateway different from an API gateway?

The mechanics are similar and the unit of control is not. An API gateway governs endpoints and methods. An MCP gateway governs tools and the arguments they are called with, which matters because the caller is a model choosing what to invoke rather than code with a fixed path. An API gateway can tell you a request was allowed. You also need to know which tool a given agent chose, with what arguments, on whose behalf.

Do we need an MCP gateway?

Not for one or two servers, where it is overhead and a well-scoped server does the job. The threshold is roughly the point where the same policy exists in more than two places, because that is when it starts drifting and nobody can answer which agent can reach what. If you cannot name every tool every agent can call without reading code, you have passed it.

Does a gateway make MCP secure?

No, and this is the claim worth being careful about. A gateway controls who may call a tool. It does not control what the tool exposes once called. A server wired to a broad database connection, behind the best gateway available, has still granted broad access to anyone the gateway lets through. The gateway is the second control. Narrow servers are the first, and no amount of gateway replaces them.

What should an MCP gateway log?

Which agent called which tool, with what arguments, on whose behalf, what came back, and whether it was allowed or refused. The arguments are the field that gets dropped and the one that matters: an entry saying a lookup tool was called tells you nothing about whether it was called on the right record. Decide retention and who can read it at design time rather than during an incident.

Can we build this ourselves or should we buy it?

Both are reasonable and the question is how many servers you expect. A thin internal gateway in front of three servers is a sensible week of work and keeps the policy in your own code. Once you are governing dozens across teams, the operational surface starts to look like a product and the arguments for buying get stronger. What rarely works is building one and then not staffing it, because an unmaintained gateway is a false sense of control.

Where does the gateway sit relative to the semantic layer?

They solve different halves and both are needed. The gateway decides whether an agent may ask. The semantic layer decides whether the answer is correct. An agent allowed through a gateway to raw tables will still answer confidently about revenue it does not understand, which is a correctness failure rather than a security one.