Best MCP gateways for company-wide AI access

What are the best MCP gateways for company-wide AI access?

Two hundred people already use ChatGPT, Claude and Cursor. Four systems hold the actual work: Salesforce, Jira, Notion and Xero. IT has been asked to put one governed layer between those clients and those systems, instead of a drawer full of pasted API keys. There is no single list of the best MCP gateways for that job. The products sold under the name come in four shapes, and the shape decides more than any feature grid does.

First the jargon. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An endpoint is the address an AI client is pointed at. OAuth is the sign-in standard that lets a person approve access in a browser instead of pasting a key. A grant is the record saying a named person may use a named resource.

Four shapes are on the market:

1. A hosted gateway over MCP servers the vendor hosts or catalogs for you.
2. A gateway in front of MCP servers or APIs you bring, self-hosted or inside an API management platform.
3. A per-member server created inside an automation account.
4. A governed MCP control plane that authors its own connectors and serves them behind one organization-wide endpoint. Elaichi is this shape.

Choose the shape first, and the vendor shortlist falls out of it. Elaichi is one of the four, and each shape gets a plain statement of where it wins.

Which four mechanics separate one MCP gateway from another?

Four mechanics decide how an MCP gateway behaves once sixty people use it. A feature grid lists checkboxes, while these four predict the tickets you will get later.

Who authors the connectors. There are three answers. The vendor writes and serves them, the vendor fronts servers somebody else runs, or you run the servers yourself. The answer decides who you call when a third party changes its API, and how a missing app gets added.

How many addresses clients point at. Some products give the organization one endpoint, some give each team one, and some give each member a server of their own. Multiply that count by the AI clients you support, then by everyone who joins or leaves. That number is the rollout, and later it is the offboarding.

Where the access decision is made. The decision can sit in a vendor's gateway, a gateway you operate, an automation account's settings, or the control plane that serves the tools. Ask who a rule can target, and whether it can name a single tool. Then ask how long a change takes to take effect, and accept a number rather than the word immediately.

What the record proves. An audit log is the append-only history of what happened. "Which of my two Notion workspaces did the agent write to?" is the first question after an unexpected change. A record that names the account the call actually reached answers it. A record of what the person asked for does not.

How do the MCP gateway shapes compare, vendor by vendor?

The table places each named vendor in its shape and answers the four mechanics from that vendor's own pages only. An ask cell means the page does not state the answer, not that the product lacks it.

The Merge Agent Handler row is all questions, because its product page states none of the four mechanics.

Which MCP gateways host the servers for you?

MintMCP and Composio both describe a gateway the vendor runs over a catalog it lists. Your AI clients connect to the vendor rather than to servers you operate. The pull of the shape is breadth on the day you sign.

MintMCP calls itself "The MCP gateway between your agents and your systems", with "thousands of MCPs they can install in one click, bundled by role, access controlled and logged" (mintmcp.com, checked October 2026). A company can publish an internal catalog of approved servers, host its own servers on the gateway behind its SSO, and "Group servers into one endpoint per role". MintMCP says every call is logged at the gateway, and that the audit log can be exported to a SIEM or streamed over OTLP (mintmcp.com, checked October 2026). What one record holds is a question to put to MintMCP. Where MintMCP and Elaichi overlap is worked through separately.

Composio's MCP Gateway page describes "one gateway, every server" and lists 1,500+ apps (composio.dev, checked September 2026). On that page, "each team gets its own MCP endpoint carrying only the tools it is permitted to use". It also lists SAML or OIDC single sign-on (SSO), so employees sign in with the company identity provider. SCIM 2.0 provisioning lets that provider create and remove accounts automatically.

Composio's enterprise page says permissions are "set administratively, per user and per role, down to the individual action". It says "every tool call is logged with the user, team, tool, action and outcome, denied calls included". Composio also offers self-hosting at the Enterprise tier (composio.dev/enterprise, checked September 2026). Per-team endpoints are easy to reason about inside one team. Ask what has to change, in every client, when one person moves team. Per-team and org-wide endpoints compares the two address models, and the Composio breakdown goes further.

Runlayer spans the first two shapes. It describes "AI enablement, security, and control in one platform", serving tools "through a governed MCP gateway across every major AI client" (runlayer.com, checked October 2026). Its docs define a connector as "a managed MCP server in Runlayer". Connectors come from three places. One is a catalog of templates maintained by Runlayer or by official vendors. The others are an MCP endpoint your team points Runlayer at, and a server you deploy to Runlayer's infrastructure (Runlayer docs, checked October 2026).

Each user still signs in to the provider once per OAuth connector, with their own credentials. Access rules can target users, groups, roles or agent accounts, down to specific tools. Runlayer's proxy evaluates them "on every tool invocation", and Runlayer says a saved rule "takes effect immediately" (Runlayer policies, checked October 2026). It runs as a hosted deployment or self-hosted in your own AWS account (Runlayer docs, checked October 2026). The docs describe adding a connector to a client from that connector's page, and give no URL pattern. So ask how many addresses a 200-person rollout creates, and what one audit entry holds.

Choose this shape if breadth of listed servers on day one matters more than who authors each one. It also assumes your security review accepts a vendor hosting the servers and the credentials, although Runlayer and Composio's Enterprise tier both offer self-hosting. Before signing, ask who fixes a catalog server when its third party changes an API: the gateway vendor, or whoever published that server.

Which MCP gateways sit in front of servers you already run?

Lunar.dev's MCPX and the MCP features of Tyk, Zuplo and Kong sit in front of servers or APIs you bring. The gateway governs the traffic, and the connectors behind it belong to whoever runs those servers.

Lunar.dev describes MCPX as a self-hosted "Enterprise MCP Gateway" that sits between agents and the MCP servers, APIs and LLM providers they use. An open-source version is on GitHub (lunar.dev, checked September 2026). Boomi announced its intent to acquire Lunar.dev on May 13, 2026, and has since completed it (boomi.com, checked September 2026). If MCPX is on your list, count your servers first.

Tyk comes from API management. Tyk's MCP Gateway proxies and governs remote MCP servers, and it can generate an MCP proxy from a REST API that Tyk already manages. Proxies fronting a remote MCP server are available on all Tyk Gateway licenses, while upstream OAuth and the REST-to-MCP proxy need Tyk Enterprise Edition (Tyk docs, checked October 2026).

Zuplo is an API gateway platform that also ships an MCP Gateway, which federates MCP servers behind one OAuth-protected gateway (zuplo.com, checked September 2026).

Kong AI Gateway supports MCP through AI MCP Server entities, which expose APIs as MCP tools (Kong docs, checked September 2026).

A proxy you run gives you anything your engineers can write, plus the pager that comes with it. API gateway MCP against MCP-native sets the two models side by side, and the real cost of self-hosting works through the math.

Choose this shape if your engineers already operate MCP servers, or an API management platform already carries your traffic. An MCP feature inside a platform you already pay for may cost less than a new product. A self-hosted gateway also keeps the traffic on infrastructure you control. Elaichi is not this shape: it is the server, not a proxy for servers you run.

How does a per-member server like Zapier MCP work across a company?

Zapier MCP gives each member a server of their own inside the company's Zapier account, one per AI client. It fits a company whose automations already live in Zapier.

Zapier describes Zapier MCP as a way for an MCP client to take actions in the apps connected to a Zapier account. It uses the same app connections and actions as Zaps (Zapier help center, checked September 2026).

Every client connects to the same Zapier URL, and "Each MCP client gets its own MCP server: one for Cursor, one for Claude, one for ChatGPT." For most MCP clients, the member signs in inside the client, and Zapier creates the server during that sign-in. Clients not on Zapier's list, and code you write, use a connection token instead. That token is long-lived, tied to one server, and "grants whoever holds it the ability to run the server's tools". Zapier says to treat it like a password and to "give each user their own server and token rather than sharing one" (Zapier docs, checked October 2026).

In an organization rollout, an admin acts in the MCP client, and "each member still signs in and runs tool calls as themselves". Admins can restrict members to a Zapier workspace, and app and action restrictions apply through MCP (Zapier rollout docs, checked October 2026).

Zapier's security page says Enterprise SAML SSO extends to MCP access. A History tab shows user-level activity logs for tool calls (Zapier security docs, checked September 2026). It does not say what happens to a member's server when that member leaves the Zapier account, so ask. One endpoint instead of one server per member works through the per-member count for a full rollout.

Choose this shape if the company already runs its automations in Zapier and the app connections people need already exist there. It suits a team small enough that one server per member stays easy to count. Nothing new has to be connected, and the app and action restrictions admins already set carry over.

Where does a governed MCP control plane like Elaichi fit?

Elaichi is the fourth shape. It authors its own connectors, serves them from its own infrastructure, and exposes every connected account through one organization-wide endpoint behind OAuth. Its answers to the four mechanics follow, and so do its limits.

Connectors. Elaichi authors, maintains and serves 500+ connectors. Your company does not run MCP servers, and Elaichi does not wrap a registry of servers other people run. That is a bet on one vendor's roadmap. When the app you need is missing, you author a custom connector from JSON config or fork a public one. Upstream changes then arrive through a review step that separates new tools, safe updates, conflicts and removals.

Addresses. Every connected account is served through one organization-wide endpoint, POST /mcp: standard MCP over Streamable HTTP, stateless, behind OAuth. A toolbox is a saved set of tools and the accounts behind them. It never gets a URL of its own, and the address carries no embedded token. Claude, ChatGPT and Cursor all point at the same URL. An admin adds it once where the client allows, and each member then connects and signs in with their own grant.

Access decision. Elaichi makes the decision in three layers, kept apart on purpose. Permissions are role-based access control (RBAC). Each member holds exactly one role, so each role is a complete persona. Sharing grants view, use or edit on a resource. Members see only the resources they own or that were shared with them, and org admins are no exception. Restrictions decide which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule on a user replaces the role rules for that user rather than adding to them. Enforcement runs at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.

Freshness. Changes land at two speeds, and an evaluation should keep them apart. A role change or a restriction change takes about two minutes to take effect, on MCP, the console and REST alike. Revoking a grant, removing a member and suspending one are all faster, and each is effective on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant's revoked state is then re-read on every single call.

Record. Elaichi writes one entry per tool-call attempt, succeeded or failed. Each entry names the account the call actually reached, read from the execution, not from what the caller intended. A call from Claude, ChatGPT or Cursor is recorded under the person who signed in, with surface mcp and the client named, and those three are marked verified. The ai_assistant actor kind marks only the Elaichi Agent. None of it is guessed from a user agent. The trail logs argument names and counts, and never argument values. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. Elaichi accepts Splunk HEC and Microsoft Sentinel as destinations but delivers events only to Datadog. The read-only Auditor seat is free, so a compliance reviewer does not consume a license. The fields an audit row must hold go into more depth.

Choose this shape if the company does not want to operate MCP servers and uses more than one AI client. It also fits when an auditor will ask about a specific call. Look elsewhere if your engineers already run MCP servers and want policy in front of them. Look elsewhere too if a long-tail app matters more than who wrote the connector. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint: per-operation permissions, a forbidden classification no OAuth scope can reach, output redaction, scope limits and full audit logging.

What should you ask every MCP gateway vendor in writing?

Ask every vendor the same eight questions, in writing, including the ones this page already places. A product page says what the vendor chose to publish. A written answer is something you can hold them to in a security review.

Merge Agent Handler gets all eight. Its product page describes a way to "securely connect your agents to thousands of third-party tools", and says nothing about the four mechanics. Its address model, credential shape and connector authorship are questions to put to Merge (merge.dev, checked September 2026). The Merge Agent Handler comparison covers that decision in more depth.

The eight questions:

• Who authors the connectors, and who fixes one when a third party changes an API?
• Is the endpoint one address for the organization, one per team, or one per member?
• Is any URL or token a bearer credential, meaning anyone who holds it can use it, and how long does it live?
• Who can a rule target, and how long does a change take to take effect, measured rather than promised?
• What is in one audit record: the account actually reached, whether an AI acted, and argument values or only names?
• What happens to a leaver's access and their connected accounts on their last day?
• Which region holds the data, and is that a guarantee or a placement preference?
• What is the billing unit: seats, tool calls or tasks?

Written answers are the comparison. A demo shows only the path the vendor chose. The billing question has its own worked comparison of per-seat and per-call pricing.

When should you buy none of these yet?

Six people using AI against two apps, with no auditor asking questions, do not need any of the four shapes. Native client connectors and careful admin settings will hold for a while. If two engineers run local MCP servers on their own laptops, a gateway is overhead. Local development does not share credentials across a company, and the developer holds the key on the machine. One team building an agent against one internal database needs a server, not a control plane.

What these products solve is shared credentials, mixed clients and the question asked afterward. The case for waiting lists the signals that say you have waited long enough.

How do you test a shortlist of MCP gateways in a week?

Run the same five steps against every vendor still on the list, and compare recordings rather than decks. Each step tests one of the four mechanics.

1. Pick one team and one system they use daily, for example support and Zendesk. Ask each vendor who authors that connector and who fixes it when Zendesk changes its API.
2. Connect the system, point Claude or ChatGPT at the vendor's endpoint, and have two people sign in as themselves. Count the addresses and tokens the rollout created.
3. Block one destructive tool for one role, then time how long the block takes to bite. In Elaichi a restriction change takes about two minutes.
4. Run five real tasks, one built to fail. Check which account each record names, whether it marks an AI as the actor, and whether argument values were written.
5. Remove one of the two people and check what their client can still do on the next call.

Step five is where the shapes separate. Browse the connector catalog for the systems that team runs, and see how each function uses governed access. Check plans and seat counting before you scope the pilot. For the definitions behind these shapes, start with what an MCP gateway is.