MCP Gateway vs Proxy vs Registry: What You Actually Need

An MCP gateway is a single endpoint that sits between your AI clients and many MCP servers. Clients connect to the gateway once; the gateway authenticates the user, decides which tools they may see and call, routes each call to the right upstream server, injects credentials, and logs what happened. Think of it as an API gateway built for the Model Context Protocol.

An MCP proxy is the simpler building block (it forwards MCP traffic, often translating transports), and a registry is a catalog that tells you which servers exist. Most teams start with direct connections, add a proxy when a transport doesn't fit, and adopt a gateway once several people or agents share the same servers. This guide explains the difference, the features worth paying for, and the gateways you can actually deploy today.

Why MCP Gateways Exist

MCP itself is a simple client-server protocol (how MCP works). Each client opens its own connection to each server. That is fine for one developer with three servers in Claude Code. It breaks down when:

• Ten clients × ten servers means a hundred config entries, each holding its own API key.
• Nobody can answer "who called which tool?" because every server logs (or doesn't log) in its own way.
• Every server implements OAuth separately, and some don't implement it at all.
• Agents see too many tools. Loading every tool from every server bloats context and raises the risk of the model picking a dangerous one (see MCP tool discovery).

A gateway centralizes those concerns in one place, the same way an API gateway did for REST microservices.

MCP Gateway vs Proxy vs Registry

The three terms overlap in marketing copy, so here is how they differ in practice:

Two practical notes:

• A gateway is a proxy with opinions. Every gateway proxies traffic; not every proxy is a gateway. If it doesn't do identity, policy and audit, call it a proxy.
• Many gateways embed a registry. ContextForge and MCPJungle both describe themselves as registry plus gateway: you register servers once, and the gateway exposes them. A public registry like the official MCP Registry (still in preview) only publishes server.json metadata; it never sits in the request path.

Core Features of an MCP Gateway

When comparing products, check these six capabilities.

1. Authentication and OAuth termination

The gateway should be the OAuth-protected resource your clients talk to. Users sign in once through your identity provider; the gateway then calls upstream servers with its own credentials. This matters because the MCP spec explicitly forbids token passthrough: per the security best practices, MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." A naive proxy that forwards the client's token to a downstream API breaks that rule. The same document describes the confused deputy attack on OAuth proxies and requires per-client consent. For the full flow, see MCP authentication and OAuth.

2. Policy and access control

Who may use which server and which tool? Good gateways tie this to identity groups or roles, not shared API keys. Microsoft's gateway uses Entra ID app roles; Kong uses Consumer and Consumer Group ACLs; Cloudflare uses Zero Trust Access policies.

3. Tool filtering and curation

Expose a subset of tools per client: read-only tools for a support bot, the full set for an engineer. This is both a security control and a context-window optimization. Look for allowlists, per-tool enable/disable, and the ability to rename or rewrite tool descriptions (Cloudflare portals support aliases and description overrides).

4. Audit logging and observability

Every tool call should be logged with the user, client, tool name, arguments (redacted where needed) and result status. OpenTelemetry export is a plus, so MCP traffic shows up next to the rest of your traces.

5. Multiplexing and aggregation

One endpoint, many servers. The gateway merges tools/list results from every upstream, namespaces the names to avoid collisions (MCPJungle uses a server__tool convention), and routes each tools/call to the right backend. Some gateways go further and wrap plain REST APIs as MCP tools (ContextForge and Kong both do this).

6. Secrets management

Upstream API keys live in the gateway, not on laptops. Docker's gateway injects secrets into server containers at start; ContextForge encrypts stored auth secrets. Some gateways also mask secrets or PII in tool responses (Lasso's plugins).

For the broader threat model these features address, read MCP security best practices.

MCP Gateway Options in 2026

Every product below was checked against its official docs or repository in October 2026.

Docker MCP Gateway

Docker's gateway runs each MCP server as an isolated container and exposes them through one endpoint. You group servers into profiles, start it with docker mcp gateway run --profile <name>, and connect Claude Code, Cursor or VS Code to it. It ships as the docker mcp CLI plugin inside Docker Desktop and also runs headless via Compose. Full walkthrough: Docker MCP Gateway setup.

Microsoft MCP Gateway

A reverse proxy and management layer that runs on Kubernetes. It handles routing (/adapters/{name}/mcp per server, plus a /mcp tool router), deploys and manages server instances, and authorizes requests with Microsoft Entra ID bearer tokens and app roles. It includes a REST control plane and a web management portal. Choose it if your servers already live in AKS or another Kubernetes cluster.

IBM ContextForge

An Apache-2.0 registry and gateway that federates MCP servers, A2A agents and REST/gRPC APIs behind one endpoint. Notable features: virtual servers (bundle selected tools into a new MCP endpoint), REST-to-MCP adaptation, an admin UI, a large plugin library and OpenTelemetry tracing. Install with:

pip install mcp-contextforge-gateway

or run the ghcr.io/ibm/mcp-context-forge container. It refuses to start without JWT_SECRET_KEY and AUTH_ENCRYPTION_SECRET; the README shows how to generate them.

Kong AI MCP Proxy

If Kong is already your API gateway, the AI MCP Proxy plugin bridges MCP and HTTP: proxy existing MCP servers, convert REST APIs into MCP tools, or aggregate tools from several plugin instances into one MCP server. Per-tool access control uses Consumer ACLs. It requires Kong Gateway 3.12+ and is part of the AI Gateway Enterprise offering.

Cloudflare MCP server portals

A managed option in Cloudflare Zero Trust. A portal puts multiple MCP servers behind one URL of the form https://subdomain.your-domain/mcp. Users sign in through Cloudflare Access; Allow policies decide which servers each user sees; admins curate which tools and prompts are exposed; Access logs tool requests. You need a domain on Cloudflare and an identity provider configured in Zero Trust. The docs warn that a blocked user can still reach an upstream server by its direct URL unless Access is also that server's OAuth provider, so lock down the origins too.

MCPJungle

A self-hosted registry plus gateway with a single endpoint (default http://localhost:8080/mcp). It supports tool groups (a curated subset exposed at its own endpoint) and an enterprise mode with client allowlists, access tokens and metrics. Install with brew install mcpjungle/mcpjungle/mcpjungle or Docker Compose.

Lasso MCP Gateway

A plugin-based local gateway (pip install mcp-gateway) that reads your existing mcp.json, launches the servers and sanitizes traffic. Plugins mask secrets and tokens (basic), mask PII via Presidio (presidio), apply Lasso's hosted guardrails (lasso, needs an API key) or trace calls (xetrack). A --scan mode checks server reputation and tool descriptions before use.

When You Need an MCP Gateway (and When You Don't)

You probably don't need one if:

• You're a single developer using a handful of local servers like Filesystem or Playwright. Your client's config file is the gateway.
• You only use first-party remote servers that already do OAuth properly, such as the GitHub MCP Server. Connect directly (remote MCP servers guide).
• You just need to turn a stdio server into an HTTP one. That's a proxy job, not a gateway job.

You likely need one if:

• More than a few people or agents share the same servers, and you want one place to add, remove or revoke access.
• Security or compliance asks for a user-attributed log of every tool call.
• Upstream API keys are currently pasted into many laptops' config files.
• You want different tool sets per team or per agent, or you need to hide destructive tools from production agents.
• You're exposing internal APIs as MCP tools and want auth, rate limits and audit in front of them.

How to choose: local developer stack, pick Docker. Kubernetes plus Entra ID, Microsoft. Already on Kong or Cloudflare, use the one you have. Open-source, self-hosted and broad protocol support, ContextForge. Lightweight team setup, MCPJungle. Data-leak protection on top of existing configs, Lasso. Whatever you pick, make sure it terminates auth instead of passing tokens through.

Next Steps

• Browse MCP servers on mcp.so to plan what your gateway will front, or explore by category.
• Try a gateway locally in ten minutes with the Docker MCP Gateway setup guide.
• Before going to production, review MCP security best practices and MCP authentication with OAuth.