# API gateway MCP vs MCP native: which shape fits

> API gateway MCP vs MCP native is a question about where the tools come from, and an existing Kong or Tyk estate is a real reason to stay put.

**TL;DR** API gateway MCP vs MCP native compares two starting points. A gateway's MCP feature puts an MCP face on APIs and servers you already run, which is the right call when the tools are your own services and your team already operates the gateway. Elaichi starts from the SaaS accounts your staff sign in to, authors the connectors itself, and serves them through one organization-wide MCP endpoint behind OAuth.

## Where this decision starts

You already run an API gateway. Kong or Tyk sits in front of your own services, with rate limits, auth and dashboards your team knows. Then support asks for Claude to reach Zendesk, finance asks for ChatGPT to read the billing system, and your gateway vendor ships an MCP feature. API gateway MCP vs MCP native is the choice hiding inside that request. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps

The deciding question is narrower than a feature comparison. Where do the tools come from, and who holds the credential that calls them.

## What does "API gateway MCP vs MCP native" actually compare?

| Axis | API gateway with MCP (Kong, Tyk) | MCP-native control plane (Elaichi) |
|---|---|---|
| Audience | Developers governing services they own | Org-wide members using AI clients against SaaS accounts |
| Auth model | Service-account keys and API tokens over your own APIs | OAuth per-employee grants over third-party accounts |
| Restrictions on tool arguments | Header, body and rate-limit policy on the request | Frozen parameters merged over the call, plus name and operation restrictions |
| Session vs call resolution | Long-lived tokens, policy cached per session | Grant revocation re-read on every call; role and restriction changes within about two minutes |
| Connector authoring | You write the upstream API or MCP server yourself | Vendor authors 450+ connectors and owns the repair path |
| Ops model | Your platform team runs the gateway | No servers to run; one `POST /mcp` endpoint for every client |

It compares two starting points. An API gateway with an 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 product starts from the SaaS accounts your staff already sign in to, and serves tools for those accounts.

That difference decides almost everything downstream. 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 NetSuite, nobody has put those behind your gateway, and the work of building and maintaining a tool surface for each one lands on somebody.

So the comparison is not "which product governs better". It is "which product's assumptions match the apps your people are asking for".

## What an MCP feature on an API gateway is built for

It is built for APIs and MCP servers the company already owns. [Tyk](https://tyk.io/docs/ai-management/mcp-gateway/overview) describes an API management platform whose MCP Gateway proxies and governs remote MCP servers, and can generate an MCP proxy from a managed REST API, with core MCP features in the open-source Tyk Gateway (checked September 2026). [Zuplo](https://zuplo.com/mcp-gateway) describes an API gateway platform that also ships an MCP Gateway, federating MCP servers behind one OAuth-protected gateway (checked September 2026). [Kong AI Gateway](https://developer.konghq.com/ai-gateway/) describes MCP support through AI MCP Server entities, including exposing APIs as MCP tools (checked September 2026).

Read the three together and the shared assumption is visible. There is an upstream, and you control it. Either it is your own REST API, or it is an MCP server somebody on your side runs. The gateway's job is to sit in the path and apply policy.

That is a good job to have if you have an upstream. It is an empty job if the thing your finance team wants to reach is a SaaS account with no MCP server in front of it.

## Why an existing Kong or Tyk estate is a strong reason to stay

If the tools your agents need are your own services, and Kong or Tyk is already the front door to them, use the gateway. The argument is not sentimental. 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 limiting and quota policy that somebody has already tuned. You have request logs landing in the observability stack your on-call uses at 3am. You have an auth story that security has already reviewed. Adding an MCP face to the same estate keeps one policy engine and one set of dashboards.

Buying a second control surface for internal APIs would mean two places to change a rule and two places to look after an incident. That is a worse outcome than a gateway feature that does most of what you wanted. If the cost of self-operating the server side is the part you are weighing, the [cost breakdown for running MCP servers yourself](/blog/self-hosted-mcp-servers-vs-control-plane/) covers it. If the request is small and recent, it may also be [too early for any gateway at all](/blog/when-you-dont-need-an-mcp-gateway/).

## Where a governed MCP control plane starts instead

Elaichi starts from the SaaS accounts, not from your services. Every account a company uses is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint: `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-user grant instead of a shared key.

Clients point at that one address and sign in. Claude, ChatGPT, Cursor, any MCP client, or the Elaichi Agent. There are no per-toolbox URLs and no embedded tokens, and there is no MCP server to create, list or revoke per user. The address is fixed and the grant is what varies. The same shape covers the admin-console rollout for each of those clients, which is the subject of [one plane, many clients](/blog/elaichi-vs-native-ai-connectors/).

Elaichi also authors the connectors it serves, 450+ of them, and maintains them on its own infrastructure. Companies do not run MCP servers for them. Connector credentials do not live in Elaichi either: a separate credential service holds per-account secrets, encrypted at rest, and owns token refresh. A failed refresh marks the connection `needs_reauth` rather than failing quietly.

## The five questions that decide it

Answer these five and the choice usually makes itself.

1. **Where do the tools come from?** Your own APIs point at the gateway. Third-party SaaS accounts point at a control plane that authors connectors.
2. **Who is the caller?** A service account calling your API is a gateway problem. A named employee in Claude or ChatGPT needs a per-user grant.
3. **How many addresses does the rollout create?** One org endpoint is one admin-console entry per client. A per-team or per-member address is a spreadsheet.
4. **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 `revoked_at` is re-read on every call, so the next call fails.
5. **What does the record say afterwards?** The first question after an unexpected change is which account was touched.

On the last two, Elaichi is specific. Role and restriction changes resolve through a 60 second cache plus edge propagation, so they take effect within about two minutes, not on the next call. Only grant revocation, member removal and suspension are effective on the next call. Every tool-call attempt writes one audit entry, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. `actor_kind` is a recorded field with values including `ai_assistant`, so an AI action is recorded as one at the point of action. Argument names and counts are logged; argument values never are.

## Drawing the line when you keep both

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 control plane. One rule, applied once, and nobody has to remember which product governs which tool.

That split keeps each system doing the thing its model fits. The gateway keeps request-level policy over code you deploy. The control plane keeps per-employee grants over accounts you do not deploy. The failure mode to avoid is governing the same tool in two places, because the rule that gets changed is the one somebody remembers.

On the control-plane side, the governance model has three layers. Roles are about 38 action strings grouped into personas, with exactly one role per member. Sharing is one grant of view, use or edit on a resource, and 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, and targets are role or user only; there is no organization target, because the organization default is the absence of a rule. Precedence runs user override, then role rule, then that default, and a user rule replaces role rules rather than layering on them. Blocks match on the tool name or the pinned operation, allows match on the pinned operation only, for a reason worth reading in [why a block matches the label and an allow does not](/blog/block-matches-name-allow-matches-operation/).

## The limits worth knowing before you pick

Both sides have edges, and the honest ones are short. On Elaichi, 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 is per-operation role checks, the `forbidden` tool classification, output redaction, OAuth scope limits and full audit logging. Residency is hard for `eu` and `us`; `apac` is a placement hint and best-effort. It is not a hard residency zone. Organization deletion tears down the workspace but has no path to purge the organization's log tenant, and it returns that residue by name.

On the gateway side, do not accept a claim about what it lacks, including from a vendor like this one. Ask the questions instead. Who authors 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?

Pricing is part of the shape too. Elaichi is two plans, Gold and Black, with a 14-day trial. Gold is $15 per user per month or $120 per user per year, 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. Suspended members and free-seat roles are excluded from the billable count, and a read-only Auditor seat is free, so a compliance reviewer does not cost a license. Current detail sits on [pricing](/pricing/).

If your answer to question one was "our own APIs", stay on the gateway. If it was a list of SaaS names, look at the [connector catalog](/connectors/), the [team rollouts](/use-cases/), or the rest of the [gateway comparisons](/blog/category/comparisons/).

## FAQ

### Is an API gateway with an MCP feature the same thing as an MCP-native product?

No. An API gateway that added MCP, such as Tyk's MCP Gateway, Zuplo's MCP Gateway or Kong AI Gateway, assumes there is an upstream you control: your own REST API, or an MCP server somebody on your side runs (vendor docs checked September 2026). An MCP-native product such as Elaichi starts from third-party SaaS accounts, authors the connectors for them, and serves them through one organization-wide MCP endpoint behind OAuth. The choice turns on where the tools come from.

### When should we keep using the API gateway we already run?

When the tools your agents need are your own services and the gateway is already the front door to them. You already have a deployment your platform team can upgrade, tuned rate limits, request logs in the observability stack your on-call uses, and an auth story security has reviewed. Buying a second control surface for internal APIs means two places to change a rule and two places to look after an incident.

### How fast does a permission change take effect in Elaichi?

Role and restriction changes take effect within about two minutes, because they resolve through a 60 second cache plus edge propagation on every surface. Only grant revocation, member removal and suspension are effective on the next call: `revoked_at` is re-read from the organization store on every single call, and removing or suspending a member revokes every live grant in the same transaction as the membership change.

### Can we run an API gateway and an MCP control plane at the same time?

Yes, and the clean split is by who owns the upstream. Internal services you deploy stay behind the API gateway. Third-party SaaS accounts go through the MCP control plane, which holds per-employee grants over accounts you do not deploy. The failure mode to avoid is governing the same tool in both places, because the rule that gets updated is the one somebody remembers.

### Does Elaichi defend the tool call against prompt-injection?

No. The prompt-injection write gate in the Elaichi agent window does not apply to `POST /mcp` and cannot, because an MCP server never sees a user prompt. What does hold on the endpoint is per-operation role checks, the forbidden tool classification, output redaction, OAuth scope limits and full audit logging of every tool-call attempt.

## Read next

- [Elaichi vs Composio for company-wide MCP access](/blog/elaichi-vs-composio/) — Elaichi vs Composio: one organization-wide MCP endpoint with connectors Elaichi authors, against per-team endpoints over a large third-party app registry.
- [Elaichi vs native AI connectors: one plane, many clients](/blog/elaichi-vs-native-ai-connectors/) — Elaichi vs native AI connectors: what a second AI client costs in repeated authorization, provisioning, audit shapes and role models, and when native is still right.
- [Lunar MCPX alternative: count your servers first](/blog/lunar-mcpx-alternative-governed-access/) — Lunar's MCPX fronts the MCP servers you already run. If you run none, the right Lunar MCPX alternative removes the servers instead of proxying them.