Top 10 MCP Gateways and Execution Layers

An MCP gateway and an execution layer both get described as the place where agent traffic is controlled. They control different hops.

A gateway sits between an MCP client and the MCP servers that expose tools. Its allow list is which caller may see and invoke which tool. An execution layer sits between a tool call and the real API. Its allow list is which API method may run, with the schema, the credential, the sandbox or production endpoint, and the retry rule. The concept page for that split is MCP gateway vs execution layer. This page is the roundup. Product behaviour below was checked against public docs and comparisons in October 2026. Where a vendor did not publish a detail, it is not filled in.

Where the allow list sits

Gateways: the allow list is the tool the caller may invoke

Docker MCP Gateway. Open source, MIT. It runs MCP servers in containers, injects credentials, and exposes one catalog to local clients, including through Docker Desktop. The allow list is which of those containerised tools a client can call. It is the strongest default for a developer machine. It is not, by itself, the control plane for every team in a company calling production APIs.

Microsoft MCP Gateway. Open source, MIT. A reverse proxy and management layer for MCP servers on Kubernetes. Callers authenticate with Entra ID, and roles decide what they can reach. The current version requires MCP 2026-07-28 clients and does not downgrade to older ones. It manages server lifecycle and routes the MCP call. The API behind a given tool is still the server's problem.

Kong. The AI MCP Proxy plugin proxies MCP servers, turns OpenAPI descriptions into MCP tools, and can aggregate tools into one endpoint. Tool ACLs decide which consumers may discover and call a tool. Those MCP plugins need an AI Gateway Enterprise license and a current Kong Gateway. Choose it when Kong is already how you publish APIs. Do not stand up Kong only to get an MCP allow list.

Tyk. MCP support ships in the open-source gateway: API-to-MCP, proxying remote MCP servers, and policies that filter tools. Rate limits can apply to a single JSON-RPC method, not only to the whole gateway. The allow list is still at the MCP hop. A tool that then charges a card is outside what that policy sees.

Cloudflare. MCP portals in the Zero Trust product accept remote HTTP MCP servers. The allow list is which remote server a user in that account may use. It is a managed hop. It is not a runtime you place next to an agent that should call the provider directly from your own network.

IBM Context Forge. Apache 2.0. A self-hosted gateway for federating MCP servers you run. The allow list is which of those servers and tools the gateway will expose. You operate the deployment. It does not replace the code that builds the provider request.

Obot. An MIT-licensed gateway for MCP servers you run yourself. Same hop as the others: who may call which tool. Treat provider credentials, retries, and sandbox versus production as a separate question. Obot's public docs do not make it the component that stores an idempotency key on a write.

agentgateway. Apache 2.0, under the Linux Foundation, written in Rust. It proxies agent and MCP traffic. The allow list, where you configure one, is on the proxy. It is infrastructure in front of servers, not a catalog of provider API schemas.

Bifrost. A self-hosted gateway, Apache 2.0, that covers MCP tool access and model routing in one process. Useful when you want one front door for both. The tool allow list is still the gateway's. A provider that applies a write twice because the tool retried without an idempotency key will not show up as two decisions in that allow list. It will show up as one successful tool call.

The execution layer: the allow list is the API method

Swytchcode is not a gateway. It does not manage the lifecycle of other MCP servers or route between them. It is an execution kernel on infrastructure you own. Agents reach it through its MCP server, the CLI, or the JavaScript and Python SDKs.

The allow list is the methods added with swy add method. If a method is not listed, it cannot run. Inputs are checked against the real schema. Policy runs before the credential is injected, and can allow, deny, or hold the call for a person. Approval workflows are on Business and Enterprise. If nobody approves within 48 hours, the call never runs. Sandbox or production is the project mode in tooling.json, set once at swy init, not an environment variable. Retries back off on rate limits. A POST or PATCH is retried only when an idempotency key is set. The response is validated, including a 200 whose body says the action failed. The request goes straight from your machine to the provider. Swytchcode does not proxy the body. Calls and policy decisions are logged locally, with secrets redacted.

That is a different hop from the gateways above. The eight stages are in AI agent execution layer architecture.

Catalog method names change. Take the current one from discover inside the project. Do not hardcode a name from a roundup.

What the gateway hop cannot see

These are the gaps that make a gateway-only setup look governed in the audit log and still move money twice.

A retry of a write, without an idempotency key, happens inside the MCP server. The gateway recorded one successful tool call.

The provider returns HTTP 200 with an error in the body. The server reports success. The gateway agrees.

A field was renamed. The server sends the old one. The failure is downstream of the gateway.

The tool's base URL is production. The gateway has no view of that URL.

If you need both, put the gateway in front for caller identity, discovery, and rate limits across many MCP servers, and put the execution layer behind the tools that become real API calls. Confirm the gateway supports the MCP transport you run. Swytchcode's MCP server docs are at cli/mcp. The pipeline docs are the execution pipeline.

How to choose

One team, agents calling provider APIs through one runtime: start with the execution layer. The question you can answer is which methods may run, on which endpoint, with which retry.

Many teams, many third-party MCP servers, a need to see who connected: add a gateway. Pick Docker for a local catalog, Microsoft's gateway if you are already on Kubernetes and Entra ID, Kong or Tyk if that gateway already publishes your APIs, Cloudflare if the MCP servers are remote and you want them inside Zero Trust.

Do not pick a gateway because the word "allow list" appeared in the docs and assume the provider write is covered. Ask which hop the list is on.

FAQ

Is an MCP gateway an execution layer?

No. The gateway governs the MCP conversation: caller, tool, rate limit. The execution layer governs the API request: schema, credential, endpoint, idempotency. Some products use both words for the first hop. Read where a refused call stops.

Which of these is open source?

Docker MCP Gateway and Microsoft MCP Gateway are MIT. Tyk's core MCP features are in the open-source gateway. Context Forge, agentgateway, and Bifrost are Apache 2.0. Kong's MCP plugins need an enterprise license. Cloudflare's portals are part of the managed product. Swytchcode is the execution runtime you run, not an open gateway you drop in front of other servers.

Can I put Swytchcode behind a gateway?

Yes. The gateway decides which clients may reach the Swytchcode MCP server. Swytchcode still decides which API methods those calls may run. The agent MCP profile can read policy. It cannot change it.

Does a gateway prevent duplicate charges?

Not by itself. Duplicate charges come from how the tool calls the API. An execution layer that retries a write only with an idempotency key is what prevents them.

What should I read next?

MCP gateway vs execution layer is the concept page. Policy-as-code for AI agents is how argument rules are written. The AI agent integration platform is the product.