Should you use an API gateway for MCP?
Use an API gateway for MCP when the tools your agents need are your own services and Kong, Tyk or Zuplo already sits in front of them. When the request names SaaS accounts instead, an MCP-native server fits better. Those apps are not behind your gateway, and putting them there would be your team's work. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
The request usually arrives in that second form. Support asks for Claude to reach Zendesk. Finance asks for ChatGPT to read Xero. Your gateway vendor has just shipped an MCP feature, and switching it on looks like the shortest path.
The deciding question is narrower than a feature comparison. It is where the tools come from, and who holds the credential that calls them.
How does a gateway's MCP feature differ from an MCP-native server?
| Question | API gateway with an MCP feature | MCP-native server (Elaichi) |
|---|---|---|
| Where the tools come from | APIs and MCP servers that already exist behind the gateway | SaaS accounts your staff sign in to |
| Who writes the tool definitions | Whoever builds the upstream API or MCP server | Elaichi, for 600+ connectors, and it owns the repair path |
| Who runs servers | Your platform team runs the gateway | Nobody on your side; one POST /mcp endpoint for every client |
| Identity on each call | Whatever your gateway policy accepts | A per-person OAuth grant |
| Control over arguments | Request policy you write at the gateway | Frozen parameters merged over the call, plus per-tool restrictions |
| When a change lands | Set by your gateway configuration | Grant revocation re-read on every call; role and restriction changes within about two minutes |
A gateway's MCP feature starts from endpoints you already operate and puts an MCP face on them. An endpoint here is one URL that accepts requests. An MCP-native server starts from the SaaS accounts your staff already sign in to, and serves tools for those accounts.
That difference decides most of what follows. If the upstream is your own service, the gateway already holds the policy, the identity model and the logs. If the upstream is Salesforce, Notion and Xero, something has to answer behind the gateway for each app: a server the vendor hosts, one you run, or one you build. Each is another address to front and another permission model to reconcile.
So the comparison is not which product governs better. It is which product's assumptions match the apps your people are asking for.
What are the MCP features in Kong, Tyk and Zuplo built for?
They are built for traffic to APIs and MCP servers that already exist (vendor pages checked October 2026). Tyk's documentation describes an MCP Gateway inside an API management platform. It proxies and governs remote MCP servers, and it can generate an MCP proxy from a REST API that Tyk already manages. Zuplo's MCP Gateway page describes federating MCP servers behind one gateway with a built-in OAuth server. Kong's AI Gateway documentation describes AI MCP Server entities that expose existing APIs as tools an agent can call.
Read the three together and they share a starting point. Something already answers behind the gateway: your own REST API, an MCP server your team runs, or a remote MCP server somebody else runs. The gateway sits in that path and applies policy.
That is a good job to have when the upstream exists. When finance wants Xero inside ChatGPT, ask any gateway vendor who supplies the thing the gateway fronts, and who keeps it working when the app changes its API.
When should you keep the gateway you already run?
Keep it when the tools your agents need are your own services and the gateway is already their front door. The reasoning is practical: you already have the parts that are expensive to acquire twice.
You have a deployment your platform team knows how to upgrade. You have rate limits and quotas that somebody has already tuned. You have request logs landing in the observability stack your on-call team reads at 3am. You have an auth setup that security has already reviewed. Adding MCP to the same estate keeps one policy engine and one set of dashboards.
A second control surface for internal APIs would mean two places to change a rule and two places to look after an incident. A gateway feature that does most of what you wanted is the better outcome. If the cost of running the server side yourself is the open question, the cost breakdown for running MCP servers yourself covers it. If the request is small and recent, it may be too early for any gateway at all.
Where does an MCP-native server start instead?
It starts from the SaaS accounts, not from your services. Elaichi connects each account a company uses once and serves the tools those accounts expose through one organization-wide MCP endpoint. That endpoint is POST /mcp: standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. OAuth here is the sign-in handshake that issues a per-person grant instead of a shared key.
Clients point at that one address and sign in: Claude, ChatGPT, Cursor or any MCP client. Nothing is issued per person or per toolbox: no separate URL, no embedded token, and no MCP server to create, list or revoke. The address is fixed; the grant is what varies.
An admin adds the address once where the client allows it, and each member then connects with their own sign-in. In Claude Team and Enterprise, an owner adds it under Organization settings > Connectors, and members connect it under Customize > Connectors. On Claude Pro and Max, each person adds it under Customize > Connectors (Claude Help Center). In Cursor, the admin MCP allowlist is Enterprise only, and adding a server to it does not push the server to anyone's machine (Cursor docs). The ChatGPT flow is in connecting ChatGPT to Elaichi, and one plane, many clients compares the three side by side.
Elaichi also serves 600+ connectors. It authors and maintains most of them on its own infrastructure, and the rest are vendors' own MCP servers that it governs under the same rules. Companies do not run MCP servers for either kind. Connector credentials do not live in Elaichi either. Each account's secrets sit in a separate credential service, encrypted at rest, and that service owns token refresh. When a refresh fails, the connection is flagged needs_reauth, so the failure is visible instead of silent.
Which five questions settle the choice?
Answer these five and the choice usually makes itself.
- Where do the tools come from? Your own APIs point at the gateway. Third-party SaaS accounts point at a server that authors connectors for them.
- Who is the caller? A service account calling your API is a gateway problem. A named employee in Claude or ChatGPT needs a grant of their own.
- How many addresses does the rollout create? One organization endpoint is added once per client, and each person signs in. A per-team or per-member address is a spreadsheet somebody has to keep current.
- What happens when somebody leaves? Ask who revokes the access and how fast. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, and the grant is re-read on every call, so the next call fails.
- What does the record say afterwards? The first question after an unexpected change is which account was touched.
Elaichi's answers to the last two are specific. Role and restriction changes wait out a 60-second cache and then reach the edge, so they take effect within about two minutes. Grant revocation, member removal and suspension land on the next call. The audit trail keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry records the connection the call actually reached, read from the execution rather than the request. A call from an MCP client is recorded under the person who signed in, with surface mcp and the OAuth client named. Claude, ChatGPT and Cursor are marked verified. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments.
Can you run a gateway and an MCP-native server side by side?
Yes. Split by who owns the upstream, not by team or by app. Internal services stay behind the gateway you already run. Third-party SaaS accounts go through the MCP-native server. One rule, applied once, and nobody has to remember which product governs which tool.
That split keeps each system on the work its design fits. The gateway keeps request-level policy over code you deploy. The MCP server keeps per-employee grants over accounts you do not deploy. The failure to avoid is governing the same tool in two places, because the rule that gets changed is the one somebody remembers.
On the Elaichi side, governance has three layers. Roles group 58 action strings, and each member holds exactly one role. Sharing is a grant of view, use or edit on a resource, and a member sees only resources they own or that someone shared with them. Restrictions decide which connectors and which individual tools a target may reach. Who a restriction can name is fixed: restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. A block can match a tool's advertised name or the operation behind it, while an allow matches only the operation. Why a block matches the label and an allow does not gives the reason.
What are the limits on each side?
Both sides have edges, and the honest ones are short. 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 Elaichi endpoint is per-operation role checks, the forbidden tool classification, output redaction, OAuth scope limits and audit logging of each call that reaches execution.
The region is chosen when the organization is created and cannot change, so an existing organization cannot move to another region later. Deleting an organization tears down the workspace and deletes every connector credential. Three stores keep residue, and the deletion names them: the audit history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Never call it total erasure.
On the gateway side, take nobody's word for what a product lacks, ours included. Ask the vendor instead:
- Who writes and updates the tool definitions for each third-party app?
- What identity does a tool call carry when an employee triggers it from Claude?
- What does the log show about which account was reached?
Price is part of the shape too. Gold lists at $15 per user per month, or $120 per user per year, in USD, and pricing shows the price for your region. Black is the other plan. There is 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. Suspended members and free-seat roles are left out of the billable count, and the read-only Auditor seat is free, so a compliance reviewer does not cost a license.
If your answer to question one was your own APIs, stay on the gateway. If it was a list of SaaS names, start with the four gateway shapes, then browse the connector catalog, the team rollouts, or the other gateway comparisons.
