MCP gateway comparison for non-engineering teams

Search for an MCP gateway comparison and you will find a good number of them, several written by the vendors themselves: TrueFoundry's ten, Obot's thirteen, and Lunar's open-source round-up among them. They compare deployment models, whether the project is open source, whether it ships a catalog, how it handles MCP-specific threats, and whether it talks to your identity provider. TrueFoundry, Composio, IBM ContextForge, Microsoft's MCP Gateway, Lasso, Lunar's MCPX, MintMCP, Obot, Kong, Portkey, Arcade and a dozen others get sorted along those columns.

Those are the right columns for the reader those posts have in mind. That reader is a platform engineer. They are standing up MCP servers, they care about where the thing runs and what it costs to operate, and the failure they are guarding against is an outage or an exposed server.

There is a second reader who is not being written for, and who is increasingly the one making the decision. That reader runs IT or operations at a company where the people who will actually use these tools sit in support, finance, sales and legal. They are not deploying servers. They are trying to answer a question from their security lead about what an assistant can reach, and a question from their support lead about why the agent cannot see Zendesk.

For that reader the columns are different. This post is the category sorted along the second set.

The question that actually decides it

Every product in this category puts something between the AI client and the tools. The thing that separates them is what that middle layer is built to know.

Most of them know about servers. A gateway that knows about servers can tell you which servers are registered, route to them, cache them, rate-limit them, scan their traffic and keep them up. The access question resolves at the connection: whoever set up the connection decided what it can reach, and every call afterwards inherits that.

A smaller number know about people. That layer resolves the call against the person the agent is acting for. Two employees pointing the same client at the same address get different tool lists, because their roles are different.

Neither is better in the abstract. They solve different failures. Server-shaped governance breaks down when the people using it have genuinely different jobs. Person-shaped governance is overhead you do not need when the caller is a batch process and there is no person behind it.

So before comparing products, answer this: is there a person behind each call, and do those people have different jobs?

If the answer is no, stop reading comparisons of this kind. You want a good proxy, and several of the open-source ones are good.

If the answer is yes, the rest of the columns matter less than you think.

What the round-ups compare, and what it tells you

Reading across the published comparisons, four columns come up on nearly every one.

Deployment model. Self-hosted, managed, or both. This is the column engineers care about most and the one non-engineers care about least. It is a real constraint if you have a policy about where software runs. It tells you nothing about whether the product can express "the support team may read tickets but not issue refunds".

Open source. Genuinely useful, and the reason several of these projects have the mindshare they do. What it does not tell you is how much of the problem is in the box. An open-source proxy plus the identity model you have to build on top of it is a different amount of work than the proxy alone suggests.

Built-in catalog. Whether the product brings its own connectors or expects you to point it at servers you already run. This one correlates strongly with which reader the product is for. A product that expects you to bring servers is talking to somebody who has servers.

Threat coverage and identity-provider support. Real and important, and the column where the category has matured fastest in the last year. Worth checking carefully, and worth checking against the vendor rather than against a competitor's table.

None of those four columns answers the question in the section above. That is not a criticism of the tables. It is a sign that the tables were built for a different decision.

How each MCP gateway behaves on that axis

Rather than a scored grid, which would go stale inside a quarter and which every vendor in the category has already published a version of, here is how the main shapes behave on the questions that matter when the user is not an engineer. Check any specific claim against the vendor; this is a map of shapes, not a scoreboard.

Native connectors in Claude and ChatGPT

The default, and for one person it is the right answer. Each person connects the apps they use, under their own account, inside their own permissions. Nothing to buy and nothing to run.

It stops working as an organization answer for a reason that has nothing to do with capability. There is no organization in it. Twenty people connect the apps they each use, and nobody has the list. When somebody leaves, the leaving checklist covers the SaaS accounts you know about, and the assistant connections are not on it because nobody wrote them down. When an auditor asks what an assistant could reach, the honest answer is that you would have to go and ask everyone.

Developer-first platforms with a large catalog

Composio and similar products bring hundreds of managed connections and handle authentication so a developer does not have to. If you are building an agent product and you need it to reach many SaaS APIs quickly, this is a strong answer and the catalog is the reason.

The governance question tends to resolve at the connection. Somebody sets up the connected account, and what an agent can do with it is decided there. That is a good fit when the agent is your product and its users are your customers. It is a less good fit when the agent is a client your employees point at company systems, because the difference between two employees is exactly the thing that does not survive.

Infrastructure gateways

TrueFoundry, Kong, Portkey, IBM ContextForge and Microsoft's MCP Gateway approach it from the traffic side. One control plane, observability, rate limits, routing, often alongside an existing AI or API gateway. If you already run one of these for model traffic, adding MCP to it is a coherent decision and the operational story is the strongest in the category.

The unit of control is the connection and the route. That is the right unit for reliability and cost. It is the wrong unit for "may this person call this operation on this account", which has to be expressed somewhere else.

Governance-first gateways

Lunar's MCPX, MintMCP, Obot and others in this group are explicitly about control rather than throughput: tool-level access control, identity-aligned attribution, audit trails, credential isolation. Lunar states that it is a Gartner Representative Vendor in an MCP Gateways category, which is a fair signal of how seriously the governance framing is being taken.

This is the closest group to the second axis, and if you are shortlisting, they belong on the list. The difference worth probing in a demo is who the product expects to operate it. Much of this group is still designed around an engineer configuring policy for servers. Ask to see the screen where a support lead changes what their own team can reach, and see whether that screen exists.

Running your own MCP servers

Entirely legitimate, and for a small engineering team with a handful of internal tools it is often the correct answer. You control everything and you pay for everything, including the part nobody budgets for: credential storage, token refresh, per-user authorization, an audit trail somebody will eventually ask you to export, and the ongoing work of keeping a dozen servers current with a spec that is still moving.

The June 2026 Enterprise-Managed Authorization extension changed the arithmetic here in a way worth understanding before committing. It lets your identity provider provision access to MCP servers centrally, so employees get connected servers on first login rather than authorizing each server themselves. That removes a genuine pain from the roll-your-own path. It does not decide which tool a given person may call once they are in, which is the part that takes the year. There is more on that in what the Enterprise-Managed Authorization extension changes.

When you do not need a gateway

Three cases, stated plainly, because a comparison that concludes "buy one" regardless of input is not a comparison.

One or two people, personal accounts. Use the native connectors. A governance layer for two people who already trust each other with everything is pure overhead.

No person behind the call. If your agent is a scheduled job running as a service account against three internal APIs, you do not have an identity problem. You have a credential-storage problem and a routing problem, and a proxy plus a secrets manager is a smaller, cheaper answer.

One team, one system, no differences. If the entire scope is your support team and your helpdesk, connect the helpdesk. A gateway earns its keep across many systems and many kinds of employee. With one of each, it is a layer between you and the thing.

The case for a gateway of the person-shaped kind starts when the same company has a support lead, a finance manager and a sales rep who should not see the same tools, and when somebody will eventually have to answer for what the assistant did.

Where Elaichi sits

We are in the governance-first group by intent, with one design decision that is the whole argument.

Every call resolves against the current role of the person the agent is acting for, rather than against the connection. Two people point the same client at the same address and get different tool lists. Nobody mints a per-person endpoint, because there is nothing to mint: the address is one address and the grant is what differs. The 400+ connectors in the catalog are connected once by whoever owns that system, shared with the teams that need them, and restricted per role or per person down to the individual tool.

Two honest notes about that claim, because the category is full of claims.

Freshness is not uniform, and we would rather say so. Revoking somebody's grant, removing them from the organization, or suspending them takes effect on the next call, with no cache in front of it. A change to somebody's role, or to a restriction, propagates in about two minutes. Both are fine for the failure people actually worry about. They are not the same number, and a vendor telling you every change is instant is telling you about their marketing rather than their cache.

The audit trail is the part we would compare on. One entry per tool call attempt, succeeded or failed, naming the tool, the account actually reached, the classification of the operation, and whether an AI was the actor, recorded as a field at the time rather than inferred later. That is the artifact somebody will ask you for, and it is worth asking every vendor on your list to show you theirs with real data in it.

Where we are not the answer: if you are a platform team deploying and operating your own MCP servers, and what you need is routing, observability and cost control in front of them, the infrastructure gateways are built for that and we are not. If your caller is a service account with no person behind it, the person-shaped model is overhead you do not need.

A shortlist that is actually a shortlist

Four questions, in order. They will cut the category faster than any grid.

1. Is there a person behind each call? If no, you want a proxy, not this.
2. Do those people have different jobs? If no, one connection per system is enough and the governance layer is ceremony.
3. Who has to operate it? If the answer is anyone other than an engineer, ask for a demo of the screen where a non-engineer changes access, and watch whether the answer is a config file.
4. What does the log look like? Ask for a real audit export, not a screenshot. Check whether it names the specific account a call reached, whether it distinguishes a human actor from an AI one, and whether a failed call is recorded as well as a successful one. Most of the difference between these products is visible in that file.

If you want to see what the fourth question looks like answered, the connector catalog lists what each connection exposes as tools, and what teams do with Elaichi arranges the same thing by who is asking. The governance side is written up separately in least privilege for AI agents and what an AI audit log has to capture.

Comparison written September 2026 from public vendor documentation. Verify anything decision-critical with the vendor directly.