MCP Gateway
An MCP gateway is a proxy that federates many Model Context Protocol servers behind one endpoint and adds the things a raw stdio server cannot: centralized authentication, rate limiting, guardrails, and a log of every tool call.
This page covers what a gateway actually does, the four thresholds at which one starts paying for itself, and how the real options differ — because they are not interchangeable. One virtualizes REST APIs as MCP servers, one containerizes every backend, one lives inside an LLM proxy, and one is hosted and issues a server URL per end user.
What an MCP gateway does
Without a gateway, every AI client holds its own server list and its own copy of every credential. Three developers running the same eight servers means twenty-four processes and twenty-four sets of API keys sitting in plaintext JSON. Add a fourth client and the configurations drift.
A gateway inverts that. Each client is configured once, pointing at the gateway, exactly where you would normally list a server in claude_desktop_config.json. The gateway holds the real server list, presents a merged tool surface, and fans each call out to the right backend — which is why a gateway is itself a compliant MCP server. From the model's side nothing looks unusual; from the operator's side there is now exactly one place to rotate a key, revoke a tool, or read an audit log.
The four capabilities that separate gateways from a shell script that starts servers are federation (one endpoint, many backends, merged tool list), auth brokering (the gateway holds upstream credentials and OAuth flows, not the client), policy (rate limits, RBAC, content guardrails applied before a call reaches a tool), and observability (OpenTelemetry traces for tool calls, the same way you trace any other service).
When you need one — and when you don't
For one person running three servers locally, a gateway is a hop and a config file for no benefit. It starts paying for itself at these four thresholds:
VS Code, Cursor and Claude Desktop drifting apart on which servers are attached is the most common first symptom. One gateway config fixes all three at once.
Stdio servers take secrets as environment variables in a config file. A gateway holds them centrally — in a secrets store, or brokered per-user via OAuth — so revocation is one action rather than a message to the team.
Tool calls are actions taken against production systems. Gateways emit OpenTelemetry traces and call logs, which is the difference between an agent you can deploy and one you can only demo.
Attach a dozen servers and the merged tool list gets long enough that model tool selection degrades and some clients hit hard limits. A gateway lets you expose a curated subset per profile instead of everything at once.
MCP gateway comparison
These are not ten versions of the same product. The "shape" column is the one to read first — a local container runtime, a Kubernetes data plane, a governance platform, a single aggregating binary and a hosted multi-tenant service solve genuinely different problems. One entry, mcpo, is not an MCP endpoint at all: it points the other way, turning MCP servers into OpenAPI services.
| Gateway | Shape | What it is best at | Deployment | License |
|---|---|---|---|---|
| ContextForge IBM ★ 4,299 | Registry + proxy | Wraps non-MCP REST/gRPC APIs as virtual MCP servers; multi-cluster federation | PyPI or container, Kubernetes at scale | Apache-2.0 |
| Agentgateway Community (Rust) ★ 4,302 | Data-plane proxy | Governs MCP, A2A and LLM traffic in one proxy; CEL-based RBAC and pluggable guardrails | Standalone YAML or Kubernetes Gateway API | Apache-2.0 |
| Docker MCP Gateway Docker ★ 1,539 | Local runtime + proxy | Each server runs in its own container; secrets live in Docker Desktop, not env vars | Docker Desktop 4.59+ CLI plugin | MIT |
| LiteLLM MCP Gateway BerriAI ★ 56,124 | Inside an LLM proxy | Per-server auth headers and alias-based tool renaming, alongside model routing | pip install 'litellm[proxy]' | MIT |
| Composio Composio ★ 29,636 | Hosted / managed | Managed auth per end user; generate a scoped server URL per user_id | Hosted API, no self-install | Commercial + OSS SDK |
| Kong Konnect Kong ★ 44 | API gateway adjacent | Fronts MCP traffic with an existing API gateway estate; agent-side Konnect analytics | Hosted remote server | Commercial |
| Obot Obot AI ★ 939 | Governance platform | Composite servers exposing selected tools from many upstreams; per-user and per-group tool access, plus device-side audit via Sentry | Container for evaluation, Kubernetes for production | MIT |
| MetaMCP MetaTool AI ★ 2,593 | Aggregator + namespaces | Namespaces you can repoint an endpoint at in one click; tool overrides and annotations to disambiguate duplicate tool names | Single Docker Compose stack | MIT |
| MCP Proxy (TBXark) Community (Go) ★ 714 | Minimal proxy | One binary, one JSON file, no control plane; authorizes OAuth downstreams once and refreshes the token for every caller | Go install, source build, or container | MIT |
| mcpo Open WebUI ★ 4,341 | MCP-to-OpenAPI proxy | Turns MCP servers into plain REST with generated OpenAPI docs — for stacks that consume OpenAPI, not MCP | uvx, pip, or container | MIT |
Star counts and repository status verified against the GitHub API on 3 August 2026. Each name links to its full listing with install commands and setup detail.
Notes on each option
IBM MCP gateway (ContextForge)
The most complete open-source option, and the one to look at if your problem includes services that will never ship an MCP server. ContextForge virtualizes REST and gRPC APIs as MCP servers — registering their operations as tools, discovering gRPC methods through server reflection — alongside federating real MCP servers. Redis-backed caching and multi-cluster federation cover Kubernetes deployments; OpenTelemetry export covers Phoenix, Jaeger, Zipkin and any OTLP backend. Ships with an admin UI, including an airgapped mode.
Full listing and install detail →Docker MCP gateway
The isolation-first option, and the easiest to adopt if your team already runs Docker Desktop. Every catalog server runs in its own container rather than as a bare npx process, secrets live in Docker Desktop's secrets store instead of environment variables, and servers are grouped into profiles that can be exported to YAML or pushed to an OCI registry — so a tool set is versioned like an image. A profile can mix catalog references, OCI images, public MCP Registry URLs and local files in one config.
Full listing and install detail →Agentgateway — the Kubernetes-native data plane
The pick if the gateway needs to be part of your service mesh rather than a developer tool. Rust proxy covering MCP, A2A and LLM traffic in one data plane, with CEL-driven RBAC, JWT/API-key/OAuth auth, and pluggable guardrails (regex, OpenAI moderation, Bedrock Guardrails, Google Model Armor, or your own webhook). Choose your deployment shape early: standalone flat-YAML and Kubernetes Gateway API modes are documented separately and are effectively different products.
Full listing and install detail →LiteLLM MCP gateway
The right answer when you already run LiteLLM as an LLM proxy — adding a second proxy for tools would be the wrong trade. MCP servers are declared under mcp_servers: in config.yaml or added through the UI, with stdio, SSE and HTTP backends all supported. Its distinguishing features are the per-server auth header convention (x-mcp-{alias}-{header}), alias-based tool renaming for shortening long tool names, and a REST path for listing and calling tools with no LLM in the loop.
Full listing and install detail →Composio — the hosted option
The managed path, and the one that fits multi-tenant products rather than internal platforms. You create a server definition with the toolkits and allowed tools it may expose, then generate a per-user URL carrying that user's connected accounts — so end-user OAuth is Composio's problem rather than yours. Two prerequisites catch people out: the auth config must exist before you create the server, and the user must have connected the toolkit first.
Full listing and install detail →Kong — API gateway adjacent
Kong appears on both sides of this conversation. Kong Gateway is a general API gateway that can front MCP traffic as part of an existing estate, and Kong publishes AI-gateway guidance for that pattern. Separately, the Konnect MCP server lets an agent read Konnect analytics and configuration. Worth flagging because most directories get it wrong: the community Kong/mcp-konnect repository is deprecated and headed for archive — Kong's supported path is the hosted remote Konnect MCP server.
Full listing and install detail →Obot — governance rather than plumbing
The option that treats the gateway as one piece of an access-control system rather than the whole product. Alongside proxying hosted and external servers, it composes virtual servers exposing selected tools from several upstreams, gates server and tool access by user or identity-provider group, and holds MCP OAuth tokens, shared credentials and Kubernetes secret bindings centrally. A second LLM gateway covers model access with per-user model policies and recorded token cost. Obot Sentry extends the audit trail onto laptops by hooking Claude Code, Codex, Cursor and VS Code directly, so local tool calls land in the same log as gateway traffic — device management is beta. The Docker quick start mounts the host Docker socket and is explicitly evaluation-only; production means the Kubernetes deployment.
Full listing and install detail →MetaMCP — namespaces and tool curation
The most direct answer to the tool-count problem. Servers are grouped into namespaces, each namespace is hosted as one aggregate MCP server on a public SSE or streamable-HTTP endpoint, and you pick which tools that namespace surfaces instead of inheriting every upstream tool. Repointing an endpoint at a different namespace is one click, so client configs stay untouched. Tool overrides and annotations let you rename or re-describe a tool, which matters when two upstream servers both ship a generic search. Two operational gotchas: CORS is enforced against APP_URL, so changing that variable makes the app unreachable from anywhere else, and the Postgres volume name is global and will collide with another Postgres container unless renamed. The maintainer has flagged review delays and now merges AI-assisted changes on an ai-dev branch — test images built from it.
Full listing and install detail →MCP Proxy (TBXark) — the minimal one
The right pick when you want plumbing and explicitly not governance: a single Go binary and one JSON config file, no database, UI or control plane. It merges tools, prompts and resources from stdio, SSE and streamable-HTTP downstreams onto one HTTP entrypoint, which is also the simplest way to put a stdio-only server on the network. Its standout feature is OAuth client support — authorize once against a downstream that needs an interactive flow, and the proxy holds and refreshes that token for every caller, removing the per-user browser step that blocks headless deployments. The container image bundles npx and uvx so it can launch Node and Python servers itself, and accepts a remote config URL, letting a fleet of proxies read one hosted file. An online converter turns an existing Claude Desktop config into its format.
Full listing and install detail →mcpo — the one that is not an MCP endpoint
Included because it is the answer for a question the rest of this page cannot address: what if the thing consuming your tools speaks OpenAPI, not MCP? mcpo wraps an MCP server and exposes its tools as REST endpoints with a generated OpenAPI schema and interactive docs, so agent frameworks, SDK codegen and existing API gateways can call MCP tools without implementing the protocol. A Claude-Desktop-format config file serves many servers at once, each on its own route with its own docs page, and --hot-reload picks up changes without downtime. It handles OAuth 2.1 upstreams via dynamic client registration, and --root-path lets it sit behind a reverse proxy. Note the repository's last push was May 2026 — stable rather than actively evolving.
Full listing and install detail →Choosing one
- You need internal REST/gRPC services reachable by agents — ContextForge, because virtualization is a first-class feature rather than something you build.
- You are worried about what a server does on a developer laptop — Docker MCP Gateway, for per-server container isolation and secrets kept out of config files.
- The gateway must live in Kubernetes next to your other proxies — agentgateway, for Gateway API integration, CEL policy and guardrails in the data path.
- You already proxy model traffic — LiteLLM, because one proxy beats two and its MCP gateway is in the product you are already running.
- Your end users each connect their own accounts — Composio, for per-user server URLs and managed third-party OAuth.
- Access has to be provable per person, not per team — Obot, for per-user and per-group tool access, centrally held credentials, and an audit trail that reaches onto laptops.
- Your client is drowning in tools — MetaMCP, because namespaces exist to expose a curated subset and can be swapped without touching client config.
- You want one binary and no control plane — MCP Proxy, which aggregates and handles downstream OAuth without asking you to run a platform.
- The consumer speaks OpenAPI, not MCP — mcpo, which is not an MCP endpoint at all: it turns servers into documented REST APIs.
MCP gateway FAQ
What is an MCP gateway?▾
An MCP gateway is a proxy that sits between your AI client and many MCP servers, exposing all of them through a single endpoint. Instead of each client (Claude Desktop, Cursor, VS Code) holding its own list of servers and its own copy of every API key, the client connects once to the gateway and the gateway handles routing, authentication, rate limiting and logging for every downstream server. It is the same architectural move an API gateway makes in front of microservices, applied to Model Context Protocol tool calls.
Do I actually need an MCP gateway?▾
For one person running three or four servers locally, no — a gateway adds a hop and a config file for no benefit. Gateways start paying for themselves at three thresholds: when more than one client has to stay in sync on the same tool set, when credentials must not live in plaintext JSON on developer laptops, and when someone needs an audit trail of which agent called which tool. A fourth arrives sooner than teams expect: client tool-count limits. Once you attach a dozen servers, the combined tool list can overflow what the model will reliably reason over, and a gateway lets you expose a curated subset.
What is the difference between an MCP gateway and an MCP server?▾
An MCP server exposes a specific capability — querying Postgres, creating a GitHub pull request, searching the web. A plain MCP proxy sits between one client and one server and only translates the transport between them, adding no policy of its own. An MCP gateway exposes other MCP servers. Confusingly, most gateways are themselves fully compliant MCP servers, because that is how the client talks to them: your client sees one server offering a merged tool list, and the gateway fans each call out to the real backend. That is why you configure a gateway in exactly the same place in claude_desktop_config.json as any other server.
What is the difference between an MCP gateway and an LLM gateway?▾
An LLM gateway (or AI gateway) proxies model traffic — routing prompts to OpenAI, Anthropic or Bedrock, tracking spend, failing over between providers. An MCP gateway proxies tool traffic. The categories are converging: LiteLLM added an MCP gateway inside what was an LLM proxy, and agentgateway covers agent-to-LLM, agent-to-tool and agent-to-agent in one data plane. If you already run an LLM gateway, check whether it now speaks MCP before adding a second proxy to the path.
Can an MCP gateway put non-MCP APIs behind MCP?▾
Yes, and this is often the real reason to deploy one. IBM ContextForge virtualizes REST and gRPC services as MCP servers, registering their operations as tools without the upstream team writing any MCP code, and it can discover gRPC methods automatically via the server reflection protocol. Practically, that means internal services that will never ship an MCP server of their own can still be reachable by an agent through the gateway.
How does authentication work through an MCP gateway?▾
It varies enough to be a selection criterion. ContextForge supports user-scoped OAuth tokens and passes an X-Upstream-Authorization header to backends. LiteLLM uses a per-server header convention (x-mcp-{alias}-{header}) so one client key can unlock differently-authenticated backends. Docker's gateway keeps credentials in Docker Desktop's secrets store and runs OAuth flows for servers that need them. Composio issues a distinct server URL per end user so the gateway holds each user's third-party connections. Ask which model matches your tenancy before you pick.
Is there an official MCP gateway from Anthropic?▾
No. Anthropic publishes the Model Context Protocol specification and a set of reference servers, but not a gateway. Every option on this page is either vendor-built (IBM, Docker, Kong) or community-built (agentgateway). The related official piece of shared infrastructure is the MCP Registry at registry.modelcontextprotocol.io, which several gateways — Docker's among them — can pull server definitions from directly.
What is an MCP gateway registry?▾
A registry is the catalog a gateway pulls server definitions from, as opposed to the proxy that runs them. Docker's gateway can reference four source types in one profile: its own catalog, an OCI image, an entry in the public MCP Registry, or a local YAML file. ContextForge bundles a registry with the proxy so registered tools, prompts and resources are discoverable centrally. In practice you want both: a registry answers 'what exists', the gateway answers 'who may call it'.
Decide what goes behind the gateway
A gateway is only as good as the servers behind it. Browse the catalog with verified repositories and install commands before you wire anything up.