Your platform team already runs Kong in front of the company's APIs, or your network sits on Cloudflare. Then operations asks for Claude to reach Salesforce, Jira, Slack and Google Workspace for three hundred people, most of them outside engineering. Both vendors document MCP features (Kong and Cloudflare, checked October 2026), so the Kong vs Cloudflare MCP gateway question looks like the whole decision. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
It is not the whole decision. The harder question is who writes the tools for each SaaS app, who signs each person in to it, and who keeps it working when the app changes. For the general gateway shape, this comparison of API gateways and MCP-native servers covers it. This post is the narrower buyer's version, for Kong and Cloudflare by name.
Kong vs Cloudflare MCP gateway, or a managed connector platform?
Pick Kong or Cloudflare when the tools are your own: APIs you already run, or MCP servers you write. Pick a managed connector platform such as Elaichi when the request is a list of SaaS apps and the people asking are not engineers.
The split follows from what each product starts with (vendor docs checked October 2026). Kong starts from your APIs and asks you to describe them as tools. Cloudflare starts from MCP servers, either ones you deploy on Workers or remote ones you add to a portal. Elaichi starts from the apps. It authors 500+ connectors itself and serves them through one organization-wide endpoint, https://api.elaichi.ai/mcp. An endpoint here is the one address every client points at.
Between the two, Kong fits when the tools are APIs you already run behind it, and Cloudflare fits when engineers build servers on Workers or put remote servers behind a portal. Cloudflare's gateway-style MCP product is MCP server portals.
None of these is better in general. Each fits a different upstream, and the sections below show where each one's work lands.
What does Kong AI Gateway do with MCP?
Kong AI Gateway turns APIs into MCP tools and proxies MCP traffic, inside a gateway your team operates. Kong's AI Gateway documentation (checked October 2026) says it "is managed through Konnect", with data plane nodes running "in your environment". It lists the job as "Turn existing APIs into tools an AI agent can discover and call over Model Context Protocol".
The building block is the AI MCP Server entity (checked October 2026). Kong's page says "Each tool needs at minimum a description and an HTTP method". Kong's API-to-tools tutorial has the reader write each tool's name, description, method and path, against the Swagger Petstore sample. The AI MCP Proxy plugin can also pass MCP requests through to an upstream MCP server. Kong marks that plugin "only available as part of our AI Gateway Enterprise offering".
Kong's access control is fine-grained. The proxy plugin evaluates allow and deny lists against Kong Consumers and Consumer Groups, at a default level and per tool. The AI MCP OAuth2 plugin (checked October 2026) validates tokens by introspection or JWKS. It also notes that "Access tokens are not forwarded to upstream services by default".
What does Cloudflare offer for MCP servers?
Cloudflare documents two MCP products that matter here: a place to run MCP servers you write, and a portal that puts several remote MCP servers behind one address. Cloudflare's remote MCP server guide (checked October 2026) deploys a server to a workers.dev subdomain. In its authentication example, "your users are redirected to GitHub to authenticate".
The second product is MCP server portals, part of Cloudflare Access in Cloudflare One. Cloudflare's MCP server portals page (checked October 2026) says a portal "centralizes multiple Model Context Protocol (MCP) servers onto a single HTTP endpoint". Users sign in through Access and "are prompted to authenticate separately to each server that requires OAuth". Admins choose and rename tools per portal, and Access logs each tool request.
The same page sets the limits. "Only remote HTTP MCP servers are supported", and "Each portal supports up to 80 MCP servers." An admin adds each server by its URL. So the portal works best when every app already publishes a remote MCP server, or when your team builds one on Workers.
Who writes the Salesforce, Jira and Slack tools on each path?
On Kong and Cloudflare, your side builds or adds the tools. On Elaichi, Elaichi writes and maintains the connectors, and your side connects accounts.
With Kong AI Gateway, someone describes each tool: name, description, method and path, per endpoint, per app. When Salesforce changes an endpoint, that description is yours to fix. With Cloudflare, a Workers server is code your engineers write and deploy. A portal can instead front an app's own remote MCP server, such as Atlassian's for Jira or Slack's (both checked October 2026). Each one still needs adding, an OAuth setup and a check on its tool names.
Elaichi starts from the other end. It authors 500+ connectors, including Salesforce, Jira and Slack, and serves them from its own infrastructure. Google Workspace arrives as several connectors, such as Gmail, Drive and Calendar. A missing app can be a custom connector, written from JSON config or forked from a public one. Why first-party authorship matters covers the repair path in detail.
How does each path sign a person in to the SaaS app?
In Elaichi, each person signs in to each app with their own account, and a separate service holds and refreshes those tokens. On Kong and Cloudflare, the per-person path to the app is something you configure.
Kong's AI MCP Server page says that, by default, "AI Gateway proxies these requests without adding credentials", and config.upstream.auth sets what Kong adds. Kong's OAuth2 plugin can swap the client's token for another one before forwarding (both checked October 2026). Ask Kong which token endpoint would issue a per-person Salesforce token, and who registers that app. On Workers, Cloudflare's authorization docs (checked October 2026) say "the MCP Server (your Worker) generates and issues its own token to the MCP client" when a third-party provider signs the user in. Cloudflare's portal supports per-user OAuth to each upstream server through its "Require user auth" setting. With it disabled, users reach the server through its admin credential. Ask Cloudflare which account each tool call reaches in each mode.
In Elaichi, a Member can connect any catalog app with their own account unless a restriction stops it. Credentials live in a separate credential service, encrypted at rest with AES-256-GCM, and that service owns refresh. A failed refresh marks the connection needs_reauth, so the failure shows. An OAuth connector connects through a default OAuth app that every organization inherits unless it brings its own. Where none exists, the catalog marks the connector, and an admin with connector-management permission stores the organization's own client ID and secret first.
How do Kong, Cloudflare and Elaichi compare side by side?
They differ most on who supplies the tools and how a person reaches each app. Vendor columns come from Kong's AI Gateway docs and Cloudflare's portal docs, checked October 2026.
| Question | Kong AI Gateway | Cloudflare (Workers and MCP server portals) | Elaichi |
|---|---|---|---|
| Where tools come from | Tool definitions you write over your APIs | MCP servers you write, or remote servers you add by URL | 500+ connectors Elaichi authors |
| Where it runs | Data planes in your environment, managed through Konnect | Workers, and portals on a domain you hold on Cloudflare | Elaichi's infrastructure, in the organization's region |
| Address for clients | Route paths you configure; a listener aggregates several | One portal URL per portal | One URL for every organization |
| Access rules | Allow and deny lists per tool, on Consumers | Access policies per portal and server; tool selection | One role per member, restrictions per role or user, frozen parameters |
| Record | Plugin logs each access attempt | Access logs each tool request | one entry per tool-call attempt, succeeded or failed, naming the account reached |
Can you connect a whole tech stack to AI assistants without building MCP servers?
Yes, if the platform already wrote the connectors. That is the case a managed connector platform is built for, and the case where a gateway leaves the most work on your side.
In Elaichi, an admin adds https://api.elaichi.ai/mcp once, each member signs in with their own OAuth grant, and members connect their apps from the catalog. On the other paths, you describe each tool in Kong, or add each server to a Cloudflare portal by its URL. The endpoint, sign-in and audit details are covered in the gateway comparison.
Two Elaichi points matter next to Kong and Cloudflare. Frozen parameters lock an argument, such as a Slack channel, so the model never sees it. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. And the organization's region (eu, us or apac) holds its data store and connector credentials, with every tool call running there.
When is Kong or Cloudflare the better choice?
Kong is the better choice when the tools are your own APIs and Kong already fronts them. Cloudflare is the better choice when your engineers are building MCP servers and want them on Workers, or want one portal over remote servers they already trust.
With Kong, an internal order API becomes tools through an AI MCP Server entity, with Consumer allow and deny lists your team already knows how to review. With Cloudflare, an engineering team writing custom servers gets Workers hosting, OAuth options and Access in one account (checked October 2026). If your apps all publish remote MCP servers, a portal over them is a reasonable shape too.
Elaichi does not fit those cases well. It does not front servers you run, and it does not govern an app's own MCP server. The cost of running your own servers is the honest test for the build path.
How does Elaichi run alongside Kong or Cloudflare?
Split by who owns the upstream: internal APIs stay behind Kong, servers your engineers write stay on Cloudflare, SaaS accounts go through Elaichi. Kong keeps request policy over APIs you deploy, and Cloudflare keeps hosting and Access for servers you build, so neither has to front Salesforce. The side-by-side split is covered in the gateway comparison.
To compare more shapes, read what an MCP gateway is, the shortlist of MCP gateways, or the Docker MCP Gateway comparison. To check your own stack, browse the connector catalog and the team rollouts.
