An MCP gateway is a service that sits between your AI agents and the MCP servers they use. Every tool call passes through it. That makes it the one place where you can check who is calling, decide whether the call may go ahead, and keep a record of what happened.

I am building one, so I have spent a lot of time on what the term should mean. Different products use it for different things. This post is my plain explanation of what a gateway does, what it does not do, and how to tell whether you need one yet.

MCP in one minute

The Model Context Protocol (MCP) is an open standard for connecting AI agents to outside systems. An MCP server offers tools, such as “create a refund” or “run a query”. The application the agent runs in acts as the client. It asks the server which tools it has, and then calls them.

Two messages matter here. tools/list asks a server what it offers. tools/call asks it to do something.

The protocol is small on purpose. It describes how a client and a server talk to each other. It does not decide which agent may call which tool, or what should happen before a risky call. The MCP specification says “there SHOULD always be a human in the loop” who can deny a tool call. How that happens is left to each application.

That gap is where a gateway fits.

What happens without one

Without a gateway, each agent connects straight to each server.

That works well for one person, one agent, and a couple of servers. It gets harder as you add more:

Every agent holds its own credentials for every system it touches.
The “are you sure?” prompt lives inside each client, and each client does it differently. An agent running on a server has nobody there to answer it.
The rules live in prompts, or in people’s heads.
When something goes wrong, the story is spread across several logs that were never meant to be read together.

None of this is a flaw in MCP. It is what you get when the protocol is the only layer everyone shares.

What an MCP gateway does

A gateway gives your agents one address to connect to. It then forwards each call to the real server behind it. Because every call goes through the same place, that place can do a few useful things.

Know who is calling. Each agent gets its own identity. A call comes from “the billing agent in production”, not from “something with a valid token”.
Control which tools an agent can reach. A server might offer twelve tools. An agent might need three.
Decide each call before it happens. This is the part I care about most. A good decision looks at the arguments, not only the tool name. Refunding SGD 20 and refunding SGD 20,000 use the same tool. They are not the same decision.
Bring in a person when it matters. Routine calls go through. A sensitive one waits for someone to approve or deny it, with the details in front of them.
Keep credentials away from the agent. The gateway holds the keys to the upstream system. The agent gets a result, not a secret it can reuse somewhere else.
Notice when a tool changes. A server can change what a tool does, or what its parameters mean. A gateway that remembers the definition you reviewed can spot the difference.
Keep one record. Who asked, what the rule decided, who approved, and what came back, in one place.

Not every product called an MCP gateway does all seven. Some are mostly routing and sign-in. Some stop at “this agent may use this tool”. The name does not tell you which kind you are looking at.

What a gateway does not do

A gateway only governs calls that go through it. If an agent still has a direct path to the same system, with its own key, that path is outside the gateway.

It does not make a badly built server safe. The server still needs to check its inputs and enforce its own permissions.

It does not replace narrow credentials either. If the key behind the gateway can delete a production database, the gateway’s rules are the only thing stopping that.

I think of it as one layer. It is the layer where a decision about a specific action can be made and written down. The other layers still matter.

When you need one

You probably need a gateway when a few of these are true:

More than one agent, or more than one team, uses the same tools.
An agent can do something that is hard to undo: move money, change access, delete data, deploy, or message a customer.
Agents run unattended, so there is nobody to click “allow”.
Someone has asked “what did the agent do, and who said it could?” and the answer took a long time.
You want a person to approve some actions, but not every action.
You use MCP servers that someone else maintains, and their tools can change without telling you.

You probably do not need one yet when:

It is just you, with local servers on your own machine.
Every tool is read-only and the data is not sensitive.
You are still finding out whether the agent is useful at all.

Adding a gateway too early is extra setup you do not need yet. The risk of waiting is that you add it after the first bad action instead of before.

Questions to ask before you pick one

If you are comparing options, these are the questions I would ask:

Can a rule look at the arguments of a call, or only at the tool name?
What happens when a tool’s definition changes after you reviewed it?
If someone approves an action, can that approval be reused for a different action later?
What is written down for each call, and can you read it without stitching logs together?
Can you watch what your rules would do before you switch them on?
Do you have to change your agent’s code, or only where it connects?

How I am approaching this with Aethis

Aethis is the gateway I am building. It is in early access, so I will keep this part short.

You point your MCP-compatible agent at an Aethis MCP server URL. Aethis governs each call and forwards it to your existing MCP server. No SDK is required.

For each call, your policy returns one of three decisions: Allow, Require Approval, or Block. A held call goes to the Approval Queue, where a reviewer can Approve Once or Deny. An approval is designed to cover that one action, not the tool in general.

New agents start in Observe Mode. Aethis evaluates your policy and records what it would have decided, while the call continues unchanged. You can see what your rules would do before they have consequences.

When a server’s tools change, Aethis pauses that connection until someone reviews the change.

Every governed call gets an Action Record. It connects the request, the policy decision, any approval, and the outcome.

The same limit applies to Aethis as to any gateway. It only governs calls that are routed through it.

What I would like to hear

If you run agents against real systems, I would like to know how you handle this today. Do you use a gateway, a proxy you built yourself, or the prompts built into your client? And which tool call would you never let an agent make on its own?

Email me at dominic.tan@aethis.io, or join the waitlist if you want to try Aethis.