AI Infrastructure · Architecture
What Is an MCP Gateway?
The complete enterprise guide: what a gateway does, how it differs from the four things people confuse it with, the four thresholds at which you actually need one, and the three problems it will not solve.
The short answer
An MCP gateway is a single governed entry point placed in front of multiple Model Context Protocol servers. Agents connect to the gateway rather than to each server directly, and it decides — per call — whether the identity behind the agent may perform that specific operation, then records the decision.
Every other gateway you have deployed was, at least partly, about throughput. This one is about jurisdiction. The problem it solves is not that calls are slow; it is that nobody can say what your agents are allowed to do.
Why is everyone suddenly asking about MCP gateways?
Because MCP worked. The Model Context Protocol made it genuinely easy to expose a tool to a model, and easy things proliferate. A protocol whose whole virtue is low friction produces, within a year, an estate nobody planned.
The arithmetic is the uncomfortable part. Direct connections between agents and servers grow multiplicatively: five agent applications reaching eight servers is forty integration points, each with its own credential, its own idea of who is calling, and its own log format — if it logs at all. Add one server and you add five connections. Add one agent and you add eight. A gateway converts that N×M into N+M, which is the same reason service meshes and API gateways exist.
But connection count is the boring half. The half that gets people’s attention is a question from someone in risk or audit: which of our AI agents can move money, and who approved that? With direct connections, answering it means interviewing every team and reading every credential grant. There is no place to stand where the answer is visible, because there is no place all the calls pass through.
A gateway is, first and last, a place to stand. Everything else it does follows from having created one.
What does an MCP gateway actually do?
Six functions. A product missing the third and fourth is a reverse proxy with a marketing page.
Know what exists
Register each server, enumerate the tools it exposes, and keep that inventory current by asking the server rather than trusting a wiki page. Most organisations discover during this step that they have three tools doing the same job and one nobody owns.
Rank it by danger
Score each tool for what it can reach and what it can destroy. This is where a “read-only” tool that writes gets caught, and it must be done from observed behaviour and schema, not from the vendor’s own description of itself.
Decide, per call
Evaluate the actual request — the tool, the argument values, the acting human’s roles, the environment, the data classification — and return a decision. This is the function that makes it a gateway rather than a proxy, and it is the one to interrogate hardest.
Keep secrets out of the agent
The agent holds one credential for the gateway. Downstream credentials live server-side and never enter a prompt, a tool description or a log. Done properly, the call executes under the acting human’s own token, so the downstream system records the real actor rather than a shared service account.
Choose where it lands
When two servers offer an equivalent capability, decide which one gets the call — on cost, region, data residency or risk. Naming and reviewing those decisions as a unit is what lets you answer “why did this call go there” without reconstructing scattered rules.
Record what happened, including the noes
One stream containing the request, the identity, the policy that matched, the outcome applied and the approver. Denials matter as much as allows: a log that records only successes cannot show a control operating.
For a concrete instance of all six, Barzel Central Gateway’s 25 tools map almost one to one onto this list: asset registration and discovery, tool risk scoring, call evaluation, policy bundles, route planning, and evidence export.
How is an MCP gateway different from an API gateway?
One sentence: an API gateway asks whether this service may call this endpoint; an MCP gateway asks whether this person, through this agent, may perform this operation on this data, right now.
The reason the difference exists is the caller. An API client follows a code path a developer wrote and reviewed; you can reason about what it will do before it runs. An agent selects its next action at runtime, frequently from content it has just read — a document, an email, a tool description written by someone outside your company. Route-level permission was sufficient when the route implied the intent. It no longer does.
| Component | What it holds | Decision it makes | What it cannot do |
|---|---|---|---|
| MCP server | Tools, resources, prompts | Whether this call is valid for this tool | See or govern any other server |
| MCP gateway | Policy, identity context, routes, audit | Whether this identity may perform this operation | Make an unsafe tool safe |
| MCP registry | Inventory, ownership, metadata | None — it records rather than rules | Block anything; it is not in the path |
| MCP proxy | Connection state | Where to forward the bytes | Judge intent; it forwards, it does not weigh |
| API gateway | Routes, keys, quotas | Whether this client may call this endpoint | Read the acting human, or weigh argument values |
These are roles, not products. A single product commonly plays several — most gateways include a registry — which is exactly why the categories get blurred in sales conversations. Ask which decision a product makes, and the fog clears. Related: MCP Gateway vs MCP Server and AI Gateway vs API Gateway.
When do you actually need an MCP gateway?
Not on day one. One server, one team, one agent is governable at the server itself, and adding a gateway then buys you a dependency and a diagram. Four thresholds change that. Crossing any one is the signal — you do not need all four, and most organisations cross the first without noticing.
-
Threshold 01
A second team runs a server
One team can hold the whole picture in their heads. Two teams cannot, and neither can see the other’s credential grants. The moment ownership splits, “what can our agents do” stops having a single answer — and nobody notices, because each team’s own answer is still correct.
-
Threshold 02
One task needs tools from two servers
Composition is where per-server governance quietly fails. Each server approves its own call correctly; neither sees the sequence. Read customer records from one server, send an email from another, and two individually reasonable permissions have combined into an exfiltration path that no single policy denied.
-
Threshold 03
A server you did not write enters the path
This is the sharpest one. A third-party server’s tool descriptions are untrusted text that your model reads and acts on, and its internals are not yours to audit. You need a control point outside that server, because every control inside it belongs to someone else. See Securing Third-Party MCP Servers.
-
Threshold 04
Someone asks for evidence
An auditor, a customer security questionnaire, or your own board. The request is never “show me your logs” — it is “demonstrate that a control operated.” That requires a record of decisions, including refusals, in one place with consistent semantics. Assembling it retroactively from five servers’ logs is a quarter of work that a gateway would have produced as a by-product.
A one-question version. If an agent did something expensive and wrong at 03:00 tomorrow, how long would it take you to establish what it did, under whose authority, and whether anything stopped it? If the honest answer is measured in days, the gateway is not premature. Barzel Central Gateway’s free tier is 1,000 calls a month — enough to route one real workflow and find out.
How does a governed call actually work?
Six stages between the model deciding to act and anything happening. Stage four is the one that distinguishes real products.
- 01 Arrival. The agent calls the gateway, not the server. It authenticates as itself and carries context about the human on whose behalf it is acting.
- 02 Resolution. The gateway maps the requested tool to a registered capability on a known server. A tool it has never seen is itself a finding.
- 03 Context assembly. Identity, roles, department, environment, target region, data classification and the literal argument values are gathered into one evaluable object.
- 04 Evaluation. Policy runs and returns an outcome. Crucially this should be deterministic — same inputs, same answer, every time. A control you cannot reproduce is not a control, and a model in this path makes the decision unreproducible by construction.
- 05 Application. Allow forwards it. Redact strips fields and forwards. Approve parks it for a human. Deny stops it. Each of these is a normal, expected result — not an error.
- 06 Recording. The event is written before the response returns, so a caller cannot act on an outcome that was never logged.
The mistake almost every client makes
Treating a policy refusal as a transport error and retrying it. A network failure means your call did not happen and retrying may help. A refusal means your call was evaluated and the answer was no; retrying identically produces the same no and a second audit event. Build two branches, not one.
How do you evaluate an MCP gateway?
Eight questions. They are ordered so that a vendor who fails the first two rarely survives the rest.
- 1. What can policy read?If it cannot distinguish two people using the same agent, it is routing with extra steps.
- 2. What outcomes can it return?Allow and deny alone create a binary teams route around. Redaction, human approval, quorum and budget ceilings should be first-class.
- 3. How do I test a policy before enforcing it?There must be a simulation path: replay real traffic, read what would have happened. Without it, every policy change is a production experiment.
- 4. What happens when it cannot reach its policy set?The answer must be “it denies.” Fail-open means the guarantee disappears precisely when something is already wrong.
- 5. What is in an audit record — and what is never in one?Action, identity, matched policy, outcome, approver. And credential values must never be written, or you cannot hand an export to a reviewer without rotating afterwards.
- 6. How are third-party servers onboarded?Governing your own servers is the easy half. Ask to see enumeration and risk scoring of a server the vendor did not write.
- 7. What does it cost in latency?Ask for a number. Then ask whether any model inference happens in the decision path; if so, you have bought latency and non-determinism together.
- 8. What happens on the day I leave?Policy and full audit history should export in a usable format, and revoking downstream access should be something you do in your own identity provider without the vendor’s cooperation.
What will an MCP gateway not solve?
We sell one. These are still true, and a vendor who will not say them is a vendor you should discount.
It does not stop prompt injection
The injected instruction still reaches the model and the model may still be persuaded. What changes is the consequence: the resulting call is judged against policy the injected text cannot edit, so the damage ceiling falls from “whatever the credential permits” to “whatever the policy permits.” That is mitigation, not immunity. See Indirect Prompt Injection Explained.
It does not make a badly designed tool safe
A tool that deletes without confirmation is dangerous at the gateway too. A gateway can refuse to expose it, gate it behind approval, or narrow its arguments — but it cannot repair it. Governance constrains reach; it does not fix design.
It is a dependency, and it fails closed
You are adding something to the path of every agent action, and the correct failure mode — denying when policy is unreachable — means a gateway outage is an agent outage. That is the right trade, but it is a real trade, and your retry logic has to know about it.
Key terms
- MCP gateway
- A single governed entry point in front of multiple MCP servers that decides, per call, whether the identity behind an agent may perform a requested operation — and records the decision.
- MCP registry
- An inventory of approved servers and tools with owners and metadata. Records what exists; enforces nothing.
- MCP control plane
- The management layer where policy, routes and inventory are authored and versioned, as distinct from the data plane carrying individual calls.
- Capability graph
- A map of which agents reach which tools on which servers. Used to surface duplicates, unowned servers and reachability nobody intended.
- Tool poisoning
- Crafting a tool’s description or schema so the model reading it is manipulated into calling it, or into supplying attacker-chosen arguments.
- Fail closed
- Denying when the policy set is unreachable, so an outage halts sensitive actions rather than permitting them by default.
Frequently asked questions
What is an MCP gateway?
A single governed entry point placed in front of multiple Model Context Protocol servers. Agents connect to it instead of to each server directly, and it decides per call whether the identity behind the agent may perform that specific operation, then records the decision. It centralises discovery, authorisation, credential handling and audit for an estate of servers.
What is the difference between an MCP gateway and an API gateway?
An API gateway routes, authenticates and rate-limits requests from a known client following a fixed code path. An MCP gateway governs a caller that chooses its next action at runtime, often from content it has just read — so the decision must weigh the acting human’s identity and the literal argument values, not only the route.
Do I need an MCP gateway if I only run one MCP server?
Usually not. One server, one team and one agent can be governed at the server itself. A gateway earns its place at one of four thresholds: a second team runs a server, one task needs tools from two servers, a server you did not write enters the path, or someone asks for evidence. Crossing any one is the signal.
What is the difference between an MCP gateway and an MCP registry?
A registry is an inventory — which servers and tools exist, who owns them, what they are for. A gateway sits in the request path and can refuse a call. A registry answers what exists; a gateway answers what may happen. Registries are often bundled into gateway products, but a registry alone enforces nothing.
Does an MCP gateway stop prompt injection?
No, and a vendor claiming otherwise is overselling. It does not prevent a model being persuaded; it limits what a persuaded model can then do. The resulting call is judged against policy the injected text cannot alter, so the blast radius falls from whatever the credential allows to whatever the policy allows.
How much latency does an MCP gateway add?
Ask for a number, and confirm no model inference sits in the decision path. Deterministic policy evaluation is a lookup and a comparison — negligible next to the model round trip that produced the tool call. A gateway that runs a model to decide has added latency and non-determinism at once.
What happens if the gateway goes down?
A correctly designed gateway fails closed: unreachable policy means deny. An outage therefore stops sensitive agent actions rather than waving them through, and your retry logic must tolerate a deny that is really an outage. A gateway that fails open offers no guarantee when guarantees matter most.
Sources and further reading
Primary specifications this article relies on. Where a claim is our judgement rather than a specified behaviour — the four thresholds, the eight evaluation questions — it is ours, and we have said so.
- Model Context Protocol specification — transport, lifecycle and the tools/list and tools/call methods.
- JSON-RPC 2.0 specification — message framing and the standard error codes a gateway passes through.
- RFC 6750: OAuth 2.0 Bearer Token Usage — the insufficient_scope challenge referenced in step-up flows.
- OWASP Top 10 for LLM Applications — prompt injection and excessive agency as named risk categories.
Try it against a real server
Before you put a gateway in front of anything, it helps to have a known-good server to test against. Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run — no signup, no key, 54 tools. A tools/list call takes about a minute and confirms your client works before you point it at anything that governs production. Setup is in the reference.
Reference documentation
Want the specification rather than the argument?
Barzel Central Gateway implements every function on this page. Its reference lists all 25 tools by name, the ten policy inputs, the six enforcement outcomes, and a step-by-step sequence for onboarding a third-party server. The free tier is 1,000 calls a month, which is enough to route a real workflow and watch a policy act on it.
Free tier · 1,000 calls/mo · on the MCPize marketplace
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.