Best MCP gateways: six questions that decide which one fits

If you run three agents and want to try something this week, start with a gateway that has a free plan and per-tool rules. If you are buying for a security review, start with where the keys live and how you get the logs out. If you already run Kubernetes and have time, an open-source gateway is a fair place to begin. Those are the three common starting points, and the rest of this post is the checklist behind them.

I build Statio, which is one of the gateways in this post, so read the verdicts with that in mind. Every claim about another product comes from that product's own pages, linked where it appears.

What does an MCP gateway have to do?

It sits between your agents and the MCP servers they call, so that one place decides who may call what, holds the credentials, and writes down what happened. MCP on its own gives you none of that. A client config has one entry per server and one key per entry, and a connected client sees every tool the server offers.

That gives six things to compare. They are the same six whether you are choosing between two vendors or between buying and building.

Can it grant one tool and not the whole server?

This is the question that separates gateways that matter from gateways that only proxy. A GitHub server exposes list_issues next to merge_pull_request. If access is per server, an agent that triages issues can also merge. The longer version of that story is in grant the tool, not the server.

Most serious gateways answer yes now. TrueFoundry says so on its MCP Gateway page:

“Each MCP Server, endpoint, or tool function can be governed by specific access rules”TrueFoundry, MCP Gateway page

Runlayer's policy documentation describes server policies scoped to exact tool names, global deny-only policies, and conditions that can check tool arguments. Statio lets you grant a server and then deny or grant single tools, and it does not look at arguments.

So the useful follow-up is not whether the gateway has per-tool rules. It is what kind:

• Names only, or arguments too. Rules on arguments let you say which tables a query may touch. They also mean you write and review policies. Per-tool grants are simpler and cover less.
• What happens when nothing matches. Runlayer's documentation says access is denied unless a policy allows it. Ask every vendor the same thing about a tool nobody has decided on yet.
• What happens when the check itself fails. In Statio, if the permission service is unreachable, a call the gateway decided a moment ago keeps working and a never-decided call is refused. Ask yours. The answer tells you whether an outage on their side stops your agents or lets them act on grants nobody could read.

The full set of approaches, and how Statio decides each call, is on the MCP permissions page.

Does every agent get its own identity?

Most agents today run on a person's key, because that is the key the engineer already had. In the logs, three agents and their owner are one name, and the only way to stop one is to revoke the shared token.

Look for agents as their own principals: a name, a credential, a status and an expiry. In Statio an agent token lasts five minutes, suspending an agent stops it getting new ones, and the log names the agent that acted. Runlayer's documentation refers to agent accounts. I did not find the equivalent stated on TrueFoundry's MCP page, so that one is a question for their sales team rather than a gap I am claiming. The same goes for the other criteria below where I name only some products.

Agent identity goes through what a non-human identity needs and how revocation should work.

Where do the upstream keys live?

Open ~/.cursor/mcp.json on a typical developer laptop and you will find live API keys in plain text, and the same ones on every other laptop on the team. A gateway should remove them from there.

Three things to ask:

1. Does the laptop hold a gateway token and nothing else?
2. Is the upstream key encrypted at rest, with the encryption key kept outside the database?
3. Can anyone, including the person who added it, read a stored key back through an API?

Statio's answers are one token on the laptop, AES-256-GCM with the key held outside the database, and no API that returns a stored credential. The details are on /security. Put the same three questions to everyone on your list and write the answers down. A vendor that cannot answer them in an email will not do better in an incident.

Managed or in your own cloud?

Managed is faster to start and someone else patches it. Running it yourself keeps keys, tool arguments and logs inside your network, which is often what a security review or a regulator asks first.

You have two ways to get there. Open-source gateways such as Docker's mcp-gateway (MIT), Microsoft's mcp-gateway (MIT) and IBM's mcp-context-forge (Apache-2.0) cost nothing to license, and you carry the operating and the patching. How much of the six criteria they cover varies by project, so read each one against the list above instead of assuming. The paid route is a vendor's self-hosted tier: TrueFoundry lists VPC, on-prem and data residency on Enterprise, and Statio Enterprise runs as licensed containers in your cloud from $15K a year.

The self-hosted MCP gateway page lays out those options side by side.

Will it run and build the servers too?

A gateway only governs servers that exist somewhere. Someone still has to run the vendor's server, or write one for the internal API that has no MCP server yet. Some gateways stop at governing and leave that to you, and some will do it.

All three paid products here will run servers for you, in different ways. Runlayer Deploy builds a server from your code and Dockerfile and runs it on Runlayer's infrastructure. TrueFoundry's MCP docs offer managed servers from its own catalogue and hosted stdio servers. Statio runs the Statio-hosted servers in its catalog, runs servers it generates on every plan, and from Team up runs your own Docker image.

Generating a server from an OpenAPI spec is narrower. TrueFoundry documents an import from an OpenAPI spec, and I did not find it in Runlayer's docs. Statio's mcp-gen does it with a choice of one tool per endpoint for small APIs or three generic tools for large ones, and each version can run on a preview URL before you promote it or roll it back. If most of what your agents need is your own internal APIs, this is the question that decides how much code you write.

Will refused calls show up in the log?

They should, because the calls that were refused are the ones you will want to read later. Two logs are worth asking about: one for tool calls, with the tool, caller, result and status, and one for changes, such as who denied a tool for which agent.

Then ask how it leaves the building. A log you can only read in the vendor's dashboard does not help a security team that works in a SIEM. In Statio, Business and up can deliver both logs by webhook, signed in an X-Statio-Signature header so your side can check where it came from. MCP audit logs covers what a useful record contains.

What does a month cost at your team size?

Prices are where gateways differ most in shape, so the number depends on your headcount. TrueFoundry's pricing page lists Pro at $25 per user per month. Statio's Team plan is $149 a month for up to 15 members, and Business, where SSO starts, is $599. Runlayer does not publish prices; its page says to contact them for a quote.

Per-user pricing is cheaper for a small team and grows with every hire. Flat pricing costs more on day one and stops growing until you hit the plan's member limit. Neither is wrong. Work out your number for twelve months from now, not today.

Which one fits which team?

Here is the sourced comparison in one table. A dash means not stated in the sources I read, not that the product lacks it.

Tick what you need and see how the three line up. It counts only what the sources state.

My own reading, for what it is worth. Pick Runlayer if you need rules on arguments and you are buying through a security process anyway: its policy model is more expressive than Statio's, and that matters for some teams. Pick TrueFoundry if you also want an LLM gateway in the same product, or if you are a small team that needs SSO now. Pick Statio if you want to start today on a free plan, want prices you can read before talking to anyone, want large internal APIs turned into servers without writing them, and per-tool grants cover what you need. Side-by-side pages: Runlayer and TrueFoundry.

Natoma belongs on any list from this year. Snowflake announced on May 27, 2026 that it is acquiring Natoma and integrating its capabilities into its AI Data Cloud, and the release does not say whether Natoma stays a standalone product. If you are evaluating it outside Snowflake, ask how it will be sold after the integration. There is a Natoma comparison with the details.

When you do not need a gateway yet

One developer, one agent, and one server that only reads: put the key in an environment variable and move on. A gateway earns its place when a second person or a second agent arrives, when a server has a tool you would hate to see called by mistake, or when someone asks you who called what last Tuesday. Before that point it is one more thing to set up.

It is also worth saying that a gateway does not fix a bad server. If an MCP server is itself malicious or compromised, the gateway limits where the damage can go, and only if it controls outbound traffic. Ask about that too.

Questions