What Actually Is an MCP Gateway?

An engineer explains that an MCP gateway solves the N×M integration problem by collapsing N agents and M tools into N+M connections, handling routing, authentication, authorization, audit, threat handling, and reliability. The landscape of MCP gateways splits into purpose-built managed services like Composio and open-source options like Obot, each with different trade-offs in governance, security, and operational overhead.

Every team that connects agents to real tools hits the same wall at roughly the same time. It usually looks like a Slack message: "Who has the Jira token?" Here's what's underneath that, and what a gateway does about it. The N×M problem You have N agents and M tools. Connect them directly, and you get N×M integrations. Each one carries its own credentials, its own auth flow, its own error handling, its own version drift. Three agents and four tools is twelve connections. Ten agents and twenty tools is two hundred. Nobody plans for that number — you arrive at it one integration at a time. A gateway collapses it to N+M. Agents connect once to the gateway. The gateway connects once to each tool. - Routing and aggregation — one endpoint fronting many MCP servers, with tool filtering so agents don't blow past context limits - Authentication — holds credentials centrally, runs OAuth flows, passes through per-user identity - Authorisation — who can call which tool; RBAC, allowlists, blocking destructive actions - Audit — logs every call: user, tool, action, outcome, including denied ones - Threat handling — tool poisoning, rug-pull updates, cross-server shadowing, prompt injection via tool descriptions - Reliability — rate limits, retries, timeouts, absorbing schema drift when upstream APIs change The threat handling deserves a note, because it's genuinely new. Tool descriptions are input the agent trusts. A server can change its tool definitions after you've approved it. Generic API security doesn't cover this, and most gateways describe their handling of it vaguely. Gateway ≠ server ≠ client Constantly confused, so: - Client — the agent Claude, Cursor, ChatGPT - Server — the thing exposing tools over MCP - Gateway — sits between them, governs the traffic And it's not an API gateway. An API gateway routes HTTP between services. An MCP gateway is protocol-aware — it understands tools and tool-call semantics, which is what lets it enforce per-tool policy. The landscape splits four ways Purpose-built managed Built for MCP from the start. They differ mainly in whether they also supply the tools. - Composio MCP gateway https://composio.dev/mcp-gateway — 1,000+ managed integrations behind per-team scoped endpoints. SCIM, action-level blocking, exportable audit. Managed, VPC, or self-hosted. - TrueFoundry — one control plane for LLM and MCP traffic. Publishes <5ms p95 overhead. Bring your own servers. - Lunar MCPX — granular RBAC, immutable audit, centralised secrets. ~4ms p99. Open source core. - MintMCP — governance-first. SOC 2 / HIPAA / GDPR log formats, SCIM-driven bundles, per-agent identity. BYO servers. - Operant AI — runtime security rather than routing. Scans servers, maps threats to OWASP, catches shadow MCP usage on dev machines. - StackOne — per-user OAuth into HRIS/ERP/CRM, plus meta-tools that keep you under client tool-count caps. Open source / self-hosted You run it, you own it. No licence cost, real operational cost. - Obot — multi-role RBAC, curated server catalogue, composite servers. Names MCP-specific threats explicitly, which most don't. Kubernetes or Docker. - Docker MCP Gateway — one container per server with signed images and resource limits. Security via isolation rather than policy. 50–200ms overhead, and no built-in RBAC or audit. - Microsoft MCP Gateway — MIT, Kubernetes-native, session-aware stateful routing. Genuinely useful plumbing; tightly coupled to AKS in practice. Not to be confused with Agent 365, which is a different product with a similar name. - IBM ContextForge — Apache 2.0. Federates MCP, A2A, REST and gRPC through one endpoint, 40+ plugins, OTel tracing. Broadest scope here; also the heaviest lift. - MCPJungle — gateway and registry in one lightweight package. Basic RBAC, minimal ceremony. - Lasso — open-source, security-first. Server reputation scanning and PII redaction, at 100–250ms. API gateways extended If you already run one, MCP becomes another middleware in a chain you understand. - Kong — Agent Gateway 3.14, April 2026 covers LLM, MCP and A2A on one runtime. Autogenerates MCP tools from existing REST endpoints, which is the shortest migration path if your services are already APIs. - Traefik Hub — MCP as middleware, acting as an OAuth 2.1 resource server. Task-Based Access Control lets policies key on amounts, time windows and record types, not just tool names. - Portkey — MCP registry alongside its LLM gateway. Remote HTTP servers only; local stdio needs wrapping. Automation platforms extended Enormous catalogues, thinner governance. Fastest route to a working prototype. - Zapier — 9,000+ apps, 30,000+ actions, browser-based setup. Task-based pricing gets unpredictable once an agent is driving. - Workato — 12,000+ enterprise connectors, existing recipes exposed over MCP. Compelling if you're already on it, hard to justify buying for MCP alone. For a longer and detailed read, check out: Best MCP Gateway https://composio.dev/content/best-mcp-gateway-for-developers The trade-off nobody states plainly Most gateways are strong on governance or strong on integration breadth . Rarely both. Governance-first products — MintMCP, Lunar, Obot — do RBAC and audit well and supply zero connectors. Bring your own servers. That's a real ongoing cost: OAuth setup, schema maintenance, security review, per tool, forever. Breadth-first products — Zapier, Workato — hand you thousands of integrations and much less control over who calls what. Work out which of those is your actual constraint before you shortlist anything. Choosing, briefly In rough order, because the early ones eliminate options: - Deployment — managed SaaS, self-hosted, or VPC. Data residency rules kill whole categories before anything else matters. - Compliance — SOC 2, ISO, HIPAA if relevant. Then check the audit trail actually exports. - Identity — SSO and SCIM, or you're provisioning access by hand. - Integration depth — do they supply connectors, or do you? - Pricing model — agents are chatty. Per-task pricing that's fine for human-triggered automation gets weird when an agent fans one request into forty tool calls. Model your volume first. Latency comes lower than you'd think. TrueFoundry publishes sub-5ms, Lunar around 4ms p99, Docker 50–200ms. Real differences — but a gateway that saves 3ms and costs six months of integration work is a bad trade for most teams. The short version If you're prototyping, grab whatever's fastest to wire up and move on. If you're going to production, the question isn't which gateway is best. It's whether connector maintenance or governance is the thing that'll actually bite you — and then picking the one that solves that, knowing you'll compromise on the other. Check out https://composio.dev/mcp-gateway https://composio.dev/mcp-gateway for building agents with secure and auditable access to tools