Ask three vendors what is an MCP gateway and three different products come back wearing the same word. One is a proxy in front of MCP servers a platform team already runs. One is a hosted address into a catalog of servers the vendor hosts. One is a control plane that is itself the MCP server and authors the connectors it serves. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps
Buying the wrong shape is not fatal. You pay for it in servers you did not want to run, or in endpoints handed out one team at a time. The sections below name who each shape is built for, and where each one costs you something.
What is an MCP gateway?
An MCP gateway is one address between AI clients and the tools those clients can call. It signs the person in, decides which tools that person may reach, and writes a record of every call. An endpoint is the address a client is pointed at, nothing more.
The arithmetic explains why the category exists. A company with three AI clients and twenty applications has sixty separate configurations to create, and later to take away. One gateway turns that into three, one per client. Clients sign in over OAuth, the standard that lets software act as a named person without holding that person's password.
Three questions separate the products. Who wrote the connector. Who fixes it when a third party changes its API. And what URL the client is pointed at, plus how many of those URLs exist once 200 people are using them.
Shape one: a proxy over MCP servers your team runs
This shape assumes the servers already exist. A platform team runs MCP servers for internal APIs, and the gateway puts one door in front of them for sign-in, policy and logging. It is infrastructure, not coverage. It does not add applications, it governs the ones already wired up.
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, with an open-source version on GitHub (lunar.dev, checked September 2026). Boomi announced intent to acquire Lunar.dev on 13 May 2026 and has since completed it (https://boomi.com/blog/lunar-dev-boomi-acquisition/, checked September 2026).
Two API management platforms sell the same shape. Tyk is an API management platform whose MCP Gateway proxies and governs remote MCP servers, and can generate an MCP proxy from a managed REST API (https://tyk.io/docs/ai-management/mcp-gateway/overview, checked September 2026). Zuplo is an API gateway platform that also ships an MCP Gateway, federating MCP servers behind one OAuth-protected gateway (https://zuplo.com/mcp-gateway, checked September 2026). Both are built for a team with REST APIs in production and a reason to expose them as tools.
The reader here is a platform engineer who owns services and has staff to keep them running. The trade-off is that the server count does not fall. Every server still needs uptime, credential rotation and an answer when an upstream API changes shape. That arithmetic is worked through in the real cost of running your own servers.
Shape two: a hosted gateway over somebody else's catalog
Here the vendor runs the servers and gives you a hosted address into the collection. Breadth arrives quickly. You did not author the connectors, so ask who repairs one before you sign.
MintMCP describes a hosted MCP gateway that hosts the MCPs and manages credentials, with hosted connectors and a large server catalog (https://www.mintmcp.com, checked September 2026). Composio Connect is an MCP server at connect.composio.dev/mcp that gives an agent access to 1000+ apps through a small set of meta-tools, with OAuth links approved in the browser (https://docs.composio.dev/docs/composio-connect, checked September 2026). The Composio MCP Gateway page says each team gets its own MCP endpoint, SSO authenticated (https://composio.dev/mcp-gateway, checked September 2026).
Governance exists in this shape, so it is not the axis of comparison. The Composio enterprise page describes permissions set administratively per user and per role down to the individual action. It also describes logging of every tool call including denied ones, and SSO over SAML and OIDC (https://composio.dev/enterprise, checked September 2026). The useful questions are where the connectors come from and how many addresses IT ends up administering. A per-team endpoint is fine at three teams and tedious at thirty. The Composio comparison works through both.
Shape three: a control plane that is the MCP server
In this shape nobody runs an MCP server. The control plane is the server, it authors the connectors it serves, and each SaaS account is connected once. Elaichi is built this way.
Elaichi serves one organization-wide endpoint, POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. There are no per-toolbox URLs and no embedded tokens. Claude, ChatGPT and Cursor are each pointed at that one address through their own admin console, and people sign in as themselves. Elaichi authors, maintains and serves 450+ connectors from its own infrastructure, so a third-party API change is Elaichi's problem rather than a ticket in your backlog.
Access has three layers and they stay distinct. Permissions come from role-based access control, and each member holds exactly one role, enforced by a unique index. Sharing is a grant of view, use or edit on a resource to a user, a team or the whole organization. A member sees only what they own or what was shared with them. Restrictions decide which connectors and which individual tools a target may reach. In short, 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. Within the winning layer allow rules union, block rules union, and blocks always beat allows. An allow rule naming nothing denies everything.
The trade-off is real. Elaichi is not a proxy in front of MCP servers you already run, so an internal server your platform team built is not fronted by it. The route in is a custom connector authored from JSON config, or a fork of a public connector that can pull upstream changes later. If your main asset is a fleet of internal servers, shape one fits you better.
Which shape owns the address, the connectors and the record?
Three columns decide most purchases: the address a client is pointed at, the party who authors the connectors, and who the product was built for.
| Shape | Address model | Who authors the connectors | Built for |
|---|---|---|---|
| Proxy over your own servers | One gateway in front of servers you operate | Your team, or the server's publisher | Platform teams with servers in production |
| Hosted gateway over a catalog | Vendor endpoint, often one per team | The vendor's catalog or the original publisher | Teams wanting breadth without operating servers |
| Native control plane | One organization-wide endpoint | The control plane vendor | IT and operations rolling out to non-engineers |
The record differs in a way that shows up during an incident. In a proxy shape the gateway sees the call and the upstream server sees the work, so two systems get read side by side. An audit log is the append-only record of who called what. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. Argument names and counts are logged. Argument values never are.
What a control plane does that routing alone cannot
A product that only routes can allow a tool or block it. Freezing an argument is the next option after those two, and it is finer than either.
Frozen parameters are a per-entry map over a tool's flattened argument space. Two things happen. Frozen keys are stripped from the advertised schema, so the model never sees them. Frozen values are merged over caller arguments at execution, so passing the key cannot un-freeze it. The full precedence is entry defaults, then caller or model arguments, then frozen parameters. That is how one workspace or one account label gets pinned while the rest of the tool stays usable. The related trap is worth reading: a restriction binds the pinned operation, not the label, and why a block matches the name and an allow matches the operation explains the asymmetry.
Which reader does each shape serve?
Match the shape to whoever is accountable when something goes wrong. If that person is a platform engineer who already owns services, a proxy keeps ownership where it is. If it is a developer shipping an agent product to end users, a hosted catalog with an SDK gets coverage fastest. If it is the person who runs IT or operations, and the users sit in support, finance, sales and legal, a control plane fits. It removes the two jobs that person cannot staff: operating servers and maintaining connectors.
Seat math matters for the third reader. Elaichi has two plans, Gold and Black, with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Gold is $15 per user per month or $120 per user per year. Suspended members and free-seat roles are excluded from the billable count, and the read-only Auditor seat is free, so a compliance reviewer does not cost a license.
What no gateway shape will do for you
No product of any of these shapes protects a raw tool call from a prompt-injection payload, and Elaichi does not claim to. An MCP server never sees the user's prompt, so there is nothing at that layer to inspect. What does hold on POST /mcp is role-based permission per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and full audit logging.
Timing is the other assumption to correct. In Elaichi a role change or a restriction change takes effect within about two minutes, because both resolve through a 60 second cache on every surface. Only three things are effective on the next call: grant revocation, member removal and suspension. removing or suspending a member revokes every live grant in the same transaction as the membership change. If your incident plan depends on cutting access at once, use removal or suspension, not a restriction edit.
When one client and one SaaS account needs none of this
One person, one AI client and one connected account do not need a gateway of any shape. The client's own connector signs that person in, the SaaS side logs what was touched, and there is no second address to reconcile. The case for waiting is set out in when a gateway is premature.
The threshold arrives with the second thing. A second client, a second account of the same application, or a leaver whose access has to be removed from more than one place at once. That is when sign-in, restrictions and one readable record start paying for themselves.
For the protocol details underneath all three shapes, browse the how MCP works archive. To see which applications a control plane covers, start with the connector catalog, or read the team use cases for the twelve teams these rollouts usually begin with.
