# Best MCP gateways for AI agents (2026)

Compare MCP gateways for credentials, tool access, per-call rules and human approval, from Docker and agentgateway to Kong, Cloudflare and withHuman.

By withHuman. Published 2026-11-09, updated 2026-11-10.

Your team's agents use MCP servers for GitHub, Linear, Stripe and your own internal APIs. Each server's API key sits in a config file on someone's laptop. Each agent sees every tool the server offers. And when an agent calls `refund_payment`, nobody knows until the money has moved.

An MCP gateway fixes that. Agents connect to the gateway instead of to each server. The gateway holds the credentials, decides which tools each agent can see, and records every call. Some gateways can also hold a call until a person approves it. If you're new to the idea, start with [what an MCP gateway is and how it works](/knowledge-base/mcp-gateway).

This guide compares nine MCP gateways for 2026. We built withHuman, so we have a point of view. We've tried to be clear about where each gateway fits, and every capability below comes from the vendor's own documentation.

## The short version

| Gateway | Type | Best fit |
| --- | --- | --- |
| withHuman | Approval gateway | Calls that should wait for a person |
| Docker MCP Gateway | Local gateway | Running MCP servers on a developer's machine |
| agentgateway | Infrastructure proxy | Platform teams on Kubernetes |
| Kong AI Gateway | API gateway | Teams already running Kong |
| Azure API Management | API gateway | Teams on Azure |
| Cloudflare MCP Server Portals | Zero trust portal | Giving employees approved MCP servers |
| Obot | MCP platform | A self-hosted catalog of MCP servers |
| IBM ContextForge | MCP platform | Federating MCP, A2A and REST behind one gateway |
| TrueFoundry | AI gateway | One gateway for LLM and MCP traffic |

## Four kinds of MCP gateways

"MCP gateway" covers products that solve different problems. Knowing which kind you need narrows the list fast.

- **Local gateways** (Docker MCP Gateway) run on a developer's machine. They start MCP servers in containers and keep secrets out of config files. They don't give an organization one place to control access.
- **Infrastructure gateways** (agentgateway, Kong, Azure API Management, Cloudflare) put MCP traffic behind the identity, network and policy layer you already run. They decide who can call which tool, then allow or block the call.
- **MCP platforms** (Obot, IBM ContextForge, TrueFoundry) add a catalog of servers, server hosting and guardrails on top of the gateway.
- **Approval gateways** (withHuman) decide each call against rules, and can hold it for a person to approve before it reaches the server.

The kinds can stack. You might run Docker's gateway for local development, and put production agents behind an approval gateway.

## What to look for in an MCP gateway

Start with what you want to prevent. If an agent shouldn't issue a $5,000 refund on its own, the gateway needs to see the refund amount before the call goes out.

- **Credentials:** Does the gateway hold the service credentials, so agents can't call the service directly? Can each person connect their own account, so the agent acts as them?
- **Tool access:** Can you give each agent, user or team only the tools it needs?
- **Call decisions:** Can rules look at a call's arguments, not just the tool name? Can a call wait for a person, and who gets notified?
- **Servers:** Does it reach remote servers over Streamable HTTP? Can it run local stdio servers, or reach servers on your private network?
- **Audit:** Can you find each call later, with who made it, what it sent and what was decided?
- **Deployment:** Do you need it hosted, self-hosted or open source?

Here's how the gateways compare.

## withHuman

*Approval gateway: rules and human approval for every tool call*

[withHuman's MCP Gateway](/docs/web-app/mcp-gateway) holds your MCP servers' credentials and sends every tool call through your [approval pipeline](/docs/concepts/approval-pipelines). The pipeline approves the call, denies it or holds it for a person. The call waits until there's a decision. If it's denied, it never reaches the server, and the agent gets the reason.

Each server can have more than one credential, called a scope. An organization credential is shared by every agent that uses it. With "each member connects their own", agents act as the person who runs them. You choose which tools each agent can see.

Rules can match the server, the tool, the scope and the call's arguments. A rule can approve reads automatically, send `refund_payment` calls over $500 to the payments team, and deny deletes in production. If the payments team doesn't answer in 10 minutes, the [escalation path](/docs/concepts/escalation-paths) can notify the finance lead. Reviewers decide in the web app or the iPhone and Android apps.

![The MCP Gateway test step showing a list_issues call from Codex to Linear, approved automatically by a rule](/images/docs/mcp-server-setup/test-light.png)

Codex listed its Linear issues through the gateway, and a rule approved the call.

Agents connect to remote servers over Streamable HTTP. For servers you run yourself, as an `npx` command or on your private network, a [tunnel](/docs/web-app/gateway-tunnels) connects them without exposing them. The [withhuman CLI](/docs/getting-started/quickstart) adds the gateway to Claude Code, Codex, Hermes and OpenClaw for you.

withHuman is [open source](https://github.com/withHumanAI/withHuman) (Apache 2.0), and you can host it yourself. The MCP Gateway is part of the hosted edition. When you host withHuman yourself, it approves agents' tool calls through hooks instead. The gateway forwards tools only, not MCP resources or prompts.

**Choose withHuman if:** some of your agents' tool calls should wait for a person, or your rules depend on what the call does, not just which tool it uses.

## Docker MCP Gateway

*Local gateway: MCP servers in containers on your machine*

The [Docker MCP Gateway](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) is an open-source (MIT) plugin for the Docker CLI. It runs each MCP server in its own container, so a server can't reach the rest of your machine. You pick servers from the Docker MCP Catalog, and your MCP client connects to the gateway as one server.

Secrets stay in Docker Desktop's secret store, not in your client's config file. Remote servers can use OAuth. Profiles let you turn servers and tools on or off, and the gateway logs and traces calls.

It's a single-machine tool. Each developer runs their own gateway with their own credentials. For organization-wide policy, Docker announced a separate MCP gateway as part of Docker AI Governance in May 2026, available by invitation.

**Choose Docker MCP Gateway if:** you want developers to run local MCP servers in isolation, without API keys in config files.

## agentgateway

*Infrastructure proxy: open-source data plane for MCP, A2A and LLM traffic*

[agentgateway](https://agentgateway.dev) is an open-source (Apache 2.0) proxy for MCP, agent-to-agent (A2A) and LLM traffic. Solo.io contributed it to the Linux Foundation, and it's now part of the Agentic AI Foundation. You run it yourself, as a binary or on Kubernetes with the Gateway API.

It connects to stdio, SSE and Streamable HTTP servers, and can combine several servers behind one endpoint. Agents sign in with MCP OAuth, JWTs or API keys. [Authorization rules](https://agentgateway.dev/docs/kubernetes/latest/mcp/tool-access/) are CEL expressions on the caller's identity and the tool name, such as `jwt.sub == "alice" && mcp.tool.name == "add_issue_comment"`. Tools a caller can't use are hidden from its tool list.

It exports OpenTelemetry metrics, logs and traces. Guardrails can call out to moderation services or your own webhook. A call is allowed or blocked. There's no state where it waits for a person.

**Choose agentgateway if:** your platform team wants an open-source data plane for agent traffic, managed like the rest of your Kubernetes networking.

## Kong AI Gateway

*API gateway: MCP plugins for Kong*

[Kong's MCP support](https://developer.konghq.com/mcp/) is a set of plugins for Kong Gateway 3.12 and later, part of AI Gateway Enterprise. The AI MCP Proxy plugin can turn an existing REST API into MCP tools, or sit in front of an existing MCP server. The AI MCP OAuth2 plugin checks the agent's token.

From 3.13, per-tool access lists allow or deny each tool by consumer or consumer group, and the tool list shows only what the caller can use. Calls feed into Kong's existing logging, audit logs and OpenTelemetry.

If your APIs already run through Kong, you keep one gateway, one set of consumers and one place for rate limits. The rules decide whether a tool can be called at all. They don't hold a call for review.

**Choose Kong if:** your APIs already go through Kong and you want to expose them, and your MCP servers, with the same controls.

## Azure API Management

*API gateway: MCP servers on Azure*

[Azure API Management](https://learn.microsoft.com/en-us/azure/api-management/mcp-server-overview) can expose a REST API as an MCP server, or put an existing remote MCP server behind API Management. Agents sign in with a subscription key or a Microsoft Entra ID token. The credential manager gets OAuth tokens for the server behind it, so agents don't hold them.

You apply API Management policies, such as rate limits, quotas and IP filtering, to the whole MCP server. Calls are logged to Azure Monitor and Application Insights. You can list servers in Azure API Center as a private registry. It supports remote servers and tools only.

Microsoft also publishes an open-source [MCP Gateway for Kubernetes](https://github.com/microsoft/mcp-gateway), which runs MCP servers as containers and routes calls with Entra ID authentication.

**Choose Azure API Management if:** you're on Azure and want MCP servers governed like your other APIs.

## Cloudflare MCP Server Portals

*Zero trust portal: one MCP address for your employees*

[MCP Server Portals](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) are part of Cloudflare One and became generally available in September 2026. A portal gives your employees one MCP address for every server you've approved. They sign in through Cloudflare Access with your identity provider.

Each server in a portal can use a shared admin credential, or ask each user to sign in with their own account. You can turn tools off per portal, and Access policies decide who can use each server. Access logs each tool request. Routing through Cloudflare Gateway adds HTTP logging and data loss prevention scanning.

Portals connect to remote servers over Streamable HTTP or SSE. Cloudflare's docs note two things to check. Users can bypass the portal through a server's direct URL unless Access is also that server's OAuth provider. And Access's temporary-authentication approvals aren't enforced for servers used through a portal.

**Choose Cloudflare if:** you already use Cloudflare Zero Trust and want to give employees a curated set of MCP servers.

## Obot

*MCP platform: open-source gateway, registry and hosting*

[Obot](https://docs.obot.ai/) is an open-source (MIT) MCP platform. It includes a gateway, a registry of approved servers and hosting for servers that run as `npx`, `uvx` or container commands, on Docker or Kubernetes. Remote servers work too.

Users sign in with your identity provider, such as Okta or Entra ID. You grant servers and tools to users or identity provider groups. Credentials can be shared or per user. [Filters](https://docs.obot.ai/functionality/filters/) are webhooks that can inspect a call and reject or change it. Audit logs can be exported on a schedule.

The free Community edition covers up to 100 users. Enterprise and the hosted Obot Cloud are paid.

**Choose Obot if:** you want to self-host a catalog of MCP servers that employees can pick from and IT can control.

## IBM ContextForge

*MCP platform: open-source gateway and registry for MCP, A2A and REST*

[ContextForge](https://github.com/IBM/mcp-context-forge) is an open-source (Apache 2.0) gateway and registry from IBM. It combines MCP servers, A2A agents and REST or gRPC APIs into virtual MCP servers. It wraps stdio servers so they can be reached over HTTP.

It supports SSO with GitHub, Google and Entra ID, and stores server credentials encrypted. About 40 plugins add checks to calls, including a PII filter and an Open Policy Agent plugin for per-tool policy. It exports OpenTelemetry traces and Prometheus metrics.

It's flexible, and you assemble the policy you want from plugins. It was at 1.0 release candidate 3 when we wrote this.

**Choose ContextForge if:** you want an open-source gateway that federates MCP, A2A and REST, and you're comfortable configuring it.

## TrueFoundry

*AI gateway: LLM and MCP traffic in one gateway*

[TrueFoundry's MCP Gateway](https://www.truefoundry.com/docs/ai-gateway/mcp-overview) is part of its AI gateway, which also routes LLM calls. It supports remote servers, hosted stdio servers, OpenAPI specs turned into tools, and virtual servers that combine several. Users can bring their own credentials through auth overrides. Guardrails run before and after a tool call, and every call is recorded.

TrueFoundry is one of the few gateways with [tool approval](https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-tool-approval). A policy selects tools by name, tools marked destructive, or all of a server's tools. It doesn't check arguments. Admins, or users with the MCP Server Approver role, get notified through Slack, email or a webhook. While a call waits, the agent receives a successful result marked pending, and it retries later. An approval can last for one call or a time window.

It runs in your VPC, on-premises or air-gapped. There's a free tier.

**Choose TrueFoundry if:** you want one vendor for your LLM and MCP gateways, and approval by tool name is enough.

## Technical comparison

The tables follow the checklist above. "Not documented" means we couldn't find it in the vendor's documentation.

### Servers and deployment

| | Open source | Where it runs | Local stdio servers | Remote servers |
| --- | --- | --- | --- | --- |
| withHuman | ✓ Apache 2.0 | Hosted or self-hosted | Through a tunnel | Streamable HTTP |
| Docker MCP Gateway | ✓ MIT | Your machine | ✓ In containers | ✓ |
| agentgateway | ✓ Apache 2.0 | Self-hosted | ✓ | Streamable HTTP, SSE |
| Kong AI Gateway | ✗ Enterprise | Self-hosted or Konnect | Not documented | Streamable HTTP |
| Azure API Management | ✗ | Azure | ✗ | Streamable HTTP, SSE |
| Cloudflare Portals | ✗ | Hosted | ✗ | Streamable HTTP, SSE |
| Obot | ✓ MIT | Self-hosted or Obot Cloud | ✓ Hosted for you | ✓ |
| IBM ContextForge | ✓ Apache 2.0 | Self-hosted | ✓ Wrapped | Streamable HTTP, SSE |
| TrueFoundry | ✗ | Your VPC or on-premises | ✓ Hosted for you | ✓ |

### Credentials and tool access

| | Service credentials | Per-user credentials | Tool access by |
| --- | --- | --- | --- |
| withHuman | ✓ Held by the gateway | ✓ Each member connects their own | Agent |
| Docker MCP Gateway | Docker Desktop secrets | On each machine | Profile |
| agentgateway | Not documented | Token exchange | CEL rules on identity and tool |
| Kong AI Gateway | Not documented | Token exchange (3.14+) | Consumer or consumer group |
| Azure API Management | ✓ Credential manager | Not documented | Whole server |
| Cloudflare Portals | ✓ Admin credential | ✓ Require user auth | Portal and Access policy |
| Obot | ✓ Shared | ✓ | User or group |
| IBM ContextForge | ✓ Encrypted | ✓ User OAuth tokens | Virtual server |
| TrueFoundry | ✓ Vault integration | ✓ Auth overrides | Tool on or off |

### Call decisions and audit

| | Rules can check arguments | Outcomes | Human approval | Audit |
| --- | --- | --- | --- | --- |
| withHuman | ✓ Conditions | Approve, deny or ask a person | ✓ Call waits, escalation paths | Audit log |
| Docker MCP Gateway | ✗ | Tool on or off | Not documented | Call logs and tracing |
| agentgateway | Not in tool rules | Allow or block | Not documented | OpenTelemetry |
| Kong AI Gateway | Not documented | Allow or block | Not documented | Audit logs, OpenTelemetry |
| Azure API Management | Not documented | Allow, block or rate limit | Not documented | Azure Monitor |
| Cloudflare Portals | DLP through Gateway | Allow or block | ✗ | Access logs |
| Obot | ✓ Filter webhooks | Allow, reject or change | Not documented | Audit logs, export |
| IBM ContextForge | ✓ Plugins, OPA | Allow, block or change | Not documented | OpenTelemetry, Prometheus |
| TrueFoundry | Guardrails | Allow, block or ask a person | ✓ By tool, agent retries | Audit trail, metrics |

## Which should you pick?

Start with the problem you have today.

- **API keys on developers' laptops:** Docker MCP Gateway keeps them in a secret store and runs servers in containers.
- **Who can use which tool, across the company:** an infrastructure gateway you already run, such as Kong, Azure API Management or Cloudflare. agentgateway if you want it open source.
- **A catalog of approved servers for employees:** Obot or ContextForge.
- **Agent calls that should wait for a person:** withHuman, or TrueFoundry if approval by tool name is enough.

If your agents can refund customers, change production or send email, controlling which tools they see isn't enough. You also need to decide each call. That's what withHuman is for. You can [set up the MCP Gateway](/docs/getting-started/set-up-mcp-gateway) with one server and see whether it fits.

## FAQ

### What is the best open-source MCP gateway?

It depends on the job. Docker MCP Gateway is best for running servers locally. agentgateway is best as a Kubernetes data plane. Obot is best for a self-hosted catalog of servers. IBM ContextForge is best for federating MCP, A2A and REST. withHuman is open source too, and is best for approving agents' tool calls. Its MCP Gateway is part of the hosted edition.

### Can an MCP gateway require human approval for tool calls?

A few can. withHuman holds the call until a person approves or denies it, with rules on the call's arguments and escalation paths for reviewers. TrueFoundry asks approvers about tools you select by name, and the agent retries once the call is approved. Most other gateways can allow, block or change a call, but not hold it for a person.

### Which MCP gateway is best for Kubernetes?

agentgateway is built for it. It runs on Kubernetes with the Gateway API and is managed like the rest of your cluster networking. Microsoft's open-source MCP Gateway also runs MCP servers as containers on Kubernetes and routes calls to them. Obot can host servers on Kubernetes too.

### Can I use my existing API gateway as an MCP gateway?

If it has MCP support. Kong (3.12 and later, with AI Gateway Enterprise) and Azure API Management can both front MCP servers and turn REST APIs into MCP tools. An API gateway without MCP support sees JSON-RPC requests, not tools, so it can't filter an agent's tool list or decide on a single call.

### Which MCP gateways can run local stdio servers?

Docker MCP Gateway, agentgateway, Obot, IBM ContextForge and TrueFoundry run or wrap stdio servers. withHuman reaches them through a tunnel. Azure API Management and Cloudflare MCP Server Portals connect to remote servers only.

### Which MCP gateways let each person connect their own account?

withHuman, Cloudflare MCP Server Portals, Obot, IBM ContextForge and TrueFoundry let each user bring their own credentials, so the agent acts as that person. agentgateway and Kong (3.14 and later) support token exchange. Docker MCP Gateway keeps credentials on each developer's machine.