The MCP Gateway Landscape in 2026: Where MCPProxy Fits

Algis Dumbris • 2026/03/15

The Cambrian Explosion of MCP Gateways

Eighteen months ago, “MCP gateway” was barely a category. Today, the awesome-mcp-gateways list on GitHub tracks 42 projects — 19 open-source and 23 commercial — and the number keeps climbing. Microsoft, IBM, Docker, Kong, Traefik, and AWS have all shipped MCP gateway solutions. At least eight new open-source gateways appeared in the last six weeks alone.

What happened? The Model Context Protocol, introduced by Anthropic in late 2024, crossed a critical adoption threshold when OpenAI, Google, and Microsoft all added MCP support. Suddenly every AI agent could talk to any tool using a standard protocol — and every organization needed something sitting between those agents and tools to enforce auth, control access, scan for threats, and log what happened.

That “something” is an MCP gateway. But the term now covers everything from a Kubernetes-native reverse proxy to a desktop-first developer tool to a commercial SaaS with 500+ managed integrations. Understanding the landscape requires separating these architectures, identifying which problems each solves, and recognizing which capabilities actually matter for your use case.

This post maps the territory, compares the major players, and explains where MCPProxy fits in.

Three Architectures, Three Philosophies

The 42 MCP gateways on the market fall into three broad architectural categories. Choosing between them is the first decision that matters.

Cloud-Native Gateways

These run in Kubernetes, scale horizontally, and assume your MCP servers are deployed as pods or remote services. They excel at multi-tenant environments where platform teams need to govern tool access across dozens of agent deployments.

Microsoft MCP Gateway is the canonical example: a C# reverse proxy with StatefulSet-based session affinity, Azure Entra ID authentication, RBAC, and a Tool Gateway Router that dynamically routes tool calls to registered servers. It is Kubernetes-native to its core — there is no standalone binary, no desktop mode. If you are an Azure shop running agents in AKS, it slots in cleanly. If you are a solo developer on a Mac, it does not apply to you.

IBM ContextForge (3.4K GitHub stars) takes the broadest approach in the category. It federates MCP, A2A, REST, and gRPC APIs behind a single endpoint with 40+ plugins, OpenTelemetry tracing, Redis-backed caching, and multi-cluster federation via mDNS auto-discovery. It is the Swiss Army knife: more protocols, more integrations, more configuration surface. The tradeoff is complexity — deploying ContextForge with its full plugin stack is a platform engineering project, not a quick install.

Kong AI Gateway extends Kong’s established API gateway with MCP proxy plugins, OAuth 2.1, and an MCP Registry for tool governance. It brings mature enterprise features — rate limiting, mTLS, ABAC (attribute-based access control) — that most MCP-only gateways lack. But it is Kong: you are buying into the full Kong Konnect ecosystem and its pricing.

Desktop-First Gateways

These run locally, optimize for individual developers or small teams, and focus on the workflow between your editor (VS Code, Cursor, Claude Code) and your MCP servers. The deployment model is a binary or CLI plugin, not a Helm chart.

Docker MCP Gateway (1.3K stars) is a Docker CLI plugin that runs MCP servers as isolated containers, manages secrets through Docker Desktop, and provides dynamic tool discovery. It integrates naturally if you already think in containers, and its interceptor system adds policy enforcement at the gateway level. The limitation is performance: 50-200ms overhead per tool call, which matters when agents chain multiple tools per turn.

MCPProxy occupies this space too, but with a different emphasis — more on that below.

Managed Platforms

The third category removes infrastructure entirely. Services like Composio (500+ managed integrations), MintMCP (SOC 2/HIPAA audit logs), and Unified Context Layer (1,000+ tools) provide hosted MCP endpoints with pre-built connectors, managed auth, and pay-per-use pricing. You do not deploy anything. You connect your agent to their endpoint and start calling tools.

The appeal is speed: you can go from zero to a working Slack + GitHub + Google Drive agent in minutes. The tradeoff is control. Your tool calls route through their infrastructure. Your data passes through their servers. You cannot inspect the gateway logic, customize the routing, or run it on your own hardware. For regulated industries or security-sensitive workloads, this is often a non-starter.

The Feature Map

Not all gateways solve the same problems. Here is how the major players compare across the capabilities that actually matter in production.

Several patterns emerge from this comparison.

Observability is table stakes. Every serious gateway now offers structured logging, metrics export, or OpenTelemetry integration. ContextForge leads here with its Phoenix/Jaeger/Zipkin tracing backends. MCPProxy’s web UI provides real-time visibility into tool calls but does not yet export to external observability stacks — this is a gap we are actively closing.

Multi-protocol is a spectrum. ContextForge supports four protocols (MCP, A2A, REST, gRPC). Kong bridges REST APIs to MCP. Most others are MCP-only. The question is whether you need multi-protocol today or whether MCP adoption will eventually make it unnecessary.

Auth strategies diverge by deployment model. Cloud-native gateways lean on identity providers (Entra ID, Keycloak). Desktop-first tools handle auth through local config or container secrets. Managed platforms abstract auth entirely.

Where MCPProxy Is Different

MCPProxy does two things that no other gateway in this landscape does: BM25 tool discovery and schema quarantine. These are not incremental features. They address fundamental problems that the rest of the market has not yet solved.

The Tool Discovery Problem

When an agent connects to 15 MCP servers exposing 200+ tools, the LLM’s context window fills with tool definitions. This creates two problems: higher token costs (each tool definition consumes tokens on every request) and worse tool selection (the model struggles to pick the right tool from a long list of similar options).

Most gateways treat this as a configuration problem — you manually curate which tools each agent can see. MCPProxy treats it as a search problem.

MCPProxy’s BM25 engine ranks available tools by relevance to the agent’s current task. When a request comes in, the engine scores all registered tools against the query using term-frequency analysis, then presents only the top-K most relevant tools to the model. The result: the agent sees 3-5 highly relevant tools instead of 200 noisy ones.

This is not vector search. We wrote extensively about why BM25 outperforms vector search for tool discovery — the short version is that tool names and descriptions are short, structured, keyword-rich text where exact term matching beats semantic similarity. BM25 requires no embedding model, no vector database, and no GPU. It runs in microseconds on a single CPU core.

No other MCP gateway offers automated relevance-based tool filtering. The rest rely on static allowlists, manual curation, or dumping everything into the context window.

The Quarantine Problem

When you connect a new MCP server, how do you know its tool definitions are safe? Tool poisoning — hiding malicious instructions in tool descriptions that the model follows but the user cannot see — is the number one MCP attack vector. Studies have found that 5.5% of open-source MCP servers exhibit tool-poisoning vulnerabilities.

Most gateways assume you have already vetted your MCP servers. They provide runtime controls (rate limiting, RBAC, allowlists) but not intake controls. MCPProxy’s quarantine system fills this gap.

When a new MCP server connects, its tool schemas are quarantined: held in a staging area where they are analyzed for known attack patterns before being released to the agent. Suspicious tools — those with hidden instructions, unusual parameter patterns, or descriptions that attempt to override agent behavior — are flagged for manual review. Only approved tools reach the agent’s context.

Combined with sensitive data detection (scanning tool responses for credentials, API keys, and PII patterns) and optional Docker isolation (running MCP servers in containers with restricted filesystem and network access), this creates a defense-in-depth pipeline that starts before the tool is ever called.

The Desktop-First Advantage

MCPProxy ships as a single Go binary. You download it, run mcpproxy serve, and you have a working gateway with a web UI, BM25 discovery, and quarantine — no Kubernetes cluster, no Docker dependency (unless you want container isolation), no cloud account.

This matters because the majority of MCP usage today is individual developers connecting Claude Code, Cursor, or VS Code to local MCP servers. Cloud-native gateways like Microsoft’s or ContextForge are not designed for this workflow. They assume platform teams, shared infrastructure, and multi-tenant access control. MCPProxy meets developers where they already are: on their laptop, in their terminal.

The Security Landscape

Security deserves special attention because it is the primary reason MCP gateways exist. The OWASP MCP Top 10 now codifies the threat model, and recent audits paint a sobering picture: 5.5% of 1,899 open-source MCP servers had tool-poisoning vulnerabilities, and over 8,000 MCP servers were found exposed without proper authentication.

Here is how the major gateways address the top threats:

Tool Poisoning Defense. MCPProxy’s quarantine catches poisoned schemas before they reach the agent. SurePath AI, a commercial platform, takes a network-layer approach — routing all MCP traffic through its proxy for real-time schema inspection and policy enforcement. Docker MCP Gateway uses cryptographic image signing and interceptors. Most others rely on runtime ACLs which do not detect poisoned descriptions.

Data Exfiltration Prevention. MCPProxy scans tool responses for sensitive patterns (API keys, credentials, PII). Open Edison focuses specifically on exfiltration prevention. ScopeGate provides granular per-agent permissions to limit what data each agent can access. The cloud-native gateways largely delegate this to existing infrastructure controls (network policies, IAM roles).

Supply Chain Security. Docker’s approach — cryptographic signing and signature verification for MCP server container images — is the most mature here. MCPProxy’s quarantine provides a lighter-weight alternative: instead of verifying the image, it verifies the schema. Both approaches have merit; they operate at different layers.

Session Security. Traefik Hub’s Triple Gate Pattern (API Gateway + AI Gateway + MCP Gateway) provides the most comprehensive session security model, with task-based access control that restricts what agents can do based on business-level objectives, not just technical roles.

Where Competitors Excel

Being honest about the landscape means acknowledging where others are ahead.

Observability: IBM ContextForge. Full OpenTelemetry integration with Phoenix, Jaeger, and Zipkin backends, plus a real-time admin UI. MCPProxy’s logging and web UI are functional but not at this level yet.

Performance: Bifrost. Eleven microseconds of overhead at 5,000 RPS is remarkable engineering. MCPProxy is fast (Go, single binary, no runtime dependencies), but we have not published formal benchmarks at that scale.

Multi-Protocol: IBM ContextForge. If you need MCP, A2A, REST, and gRPC behind one gateway today, ContextForge is the only open-source option. MCPProxy is MCP-only and likely to stay that way — we would rather do MCP extremely well than do four protocols adequately.

Enterprise Integration: Kong AI Gateway. Kong’s existing customer base, compliance certifications, and enterprise support infrastructure are hard to replicate. If you are already a Kong shop, adding MCP governance through Kong makes more sense than introducing a new tool.

Managed Ease of Use: Composio. Five hundred pre-built integrations with managed auth means you can build a working agent in minutes, not hours. MCPProxy requires you to set up and manage your own MCP servers. That is intentional — we believe in infrastructure you control — but it is undeniably more work.

Market Trajectory

Three patterns are shaping where the MCP gateway market goes from here.

Consolidation is coming. Forty-two gateways is not sustainable. The market will consolidate around 5-8 major players within 12-18 months, likely along deployment-model lines: one or two cloud-native winners, one or two desktop-first tools, and a handful of managed platforms. Open-source projects with strong communities and clear differentiation will survive. Feature-identical clones will not.

Platform vendors will absorb the category. AWS has already added MCP proxy support to API Gateway. Azure has MCP support in API Management. Kong and Traefik treat MCP as an extension of their existing gateway products. The standalone “MCP gateway” may eventually become a feature rather than a product — which makes differentiated capabilities like BM25 discovery and quarantine more important, not less.

Security becomes the differentiator. As basic gateway functionality commoditizes (auth, routing, logging), the security layer becomes the primary differentiator. The gateways that can detect tool poisoning, prevent data exfiltration, and enforce granular access policies will win. This is where MCPProxy’s quarantine + sensitive data detection pipeline positions us well.

Where MCPProxy Goes from Here

We are building MCPProxy as the security-first, developer-first MCP gateway. The roadmap reflects this:

Near-term (Q2 2026): OpenTelemetry export for structured observability, expanded quarantine rules covering the full OWASP MCP Top 10, and improved BM25 ranking with field-weighted scoring across tool names, descriptions, and parameter schemas.

Medium-term (H2 2026): Lightweight OS-level sandboxing for stdio MCP servers using Linux Landlock (so you get filesystem restrictions without Docker overhead), expanded sensitive data detection patterns, and a public benchmark suite comparing gateway performance overhead.

Ongoing: Staying lean. MCPProxy will remain a single binary that you can download and run in 30 seconds. We will not become a platform. We will not require a cloud account. We will not add protocols we cannot secure properly.

The MCP gateway market is large and growing. There is room for specialized tools that do specific things exceptionally well. MCPProxy’s bet is that intelligent tool discovery and pre-execution security scanning are those things — and that developers will choose the gateway that makes their agents both smarter and safer.

MCPProxy is open source at github.com/gptscript-ai/mcpproxy. Star the repo, file issues, or try it with mcpproxy serve.