Control plane vs MCP gateway: when each one fits

An MCP gateway is a proxy that sits in front of one or more MCP servers and forwards tool calls, usually adding auth, rate limiting, or transport translation at the wire. A control plane is the workspace around those calls: it owns which tools exist for a team, which credentials belong to whom, where execution happens, and what gets recorded. The two solve adjacent problems. This post defines each shape precisely, lists where each one fits, and explains why they compose rather than compete.

The gateway model

An MCP gateway is fundamentally a request forwarder. It accepts an inbound MCP connection from an agent, routes the tool call to the right upstream MCP server, and returns the response. Around that pipe, gateways typically add a thin layer of operational concerns: routing across multiple upstream MCP endpoints, transport bridging (stdio ↔ SSE ↔ Streamable HTTP), OAuth interception so the agent does not handle provider tokens directly, request signing or header injection, per-route rate limiting, and structured logging of the request line. The gateway is stateless or thin-state by design — it does not own which tools a team has installed, which agent owns which credential, or what happened across last week’s runs. It owns the hop. Anything past the hop is somebody else’s problem.

The control plane model

A control plane owns the workspace that wraps those hops. Tenancy is workspace-scoped: a team is the unit of ownership, not an individual user. The plane keeps the source-of-truth registry of installed plugins and the tools they expose, the shared OAuth client configuration and per-tool credential grants, the workspace-scoped memory primitives that outlive any single agent, the policies that decide which agent can call which tool with which arguments, and the run history that proves what happened. A control plane is not merely a smarter proxy — it owns server-side execution. When an agent submits work, the plane resolves the right plugin source for the workspace, dispatches the call inside an isolated runtime, exposes orbit primitives (storage, cache, db, ai, tools, jobs) to the submitted code, and records the run, the request, and every span the execution emitted. The plane is the thing that survives an agent restart, an offboarding, or a security review.

Where each fits

The decision is not religious. It is about which problem is actually in front of you.

Pick a gateway when

You already have a curated catalogue of MCP servers and only need transport bridging or OAuth interception at the edge. Per-agent identity is already solved by another system — an IdP, a sidecar, a developer-machine credential store — and you do not need a shared team workspace around the calls. You want a thin layer to normalize how multiple agents reach a small number of upstream MCP endpoints, plus rate limits and structured access logs. Audit needs are local-first; inspecting a multi-step run across agents is not on the near-term roadmap.

Pick a control plane when

More than one agent and more than one human share the same set of tools. Credentials need to live with the team, not in per-agent configs. Memory has to survive across agents and across runs so one bot can read what another bot wrote. You need server-side execution — an isolated sandbox, not just request forwarding — because submitted code calls multiple tools, persists state, and may run longer than a single request. Authorization is per-tool, not per-endpoint, and policy lives at the workspace level. Runs have to be traced and inspectable for incident review or compliance, with the audit boundary drawn around the workspace rather than around each agent process.

Hybrid is real

These shapes compose. A gateway in front of a fleet of MCP servers can hand normalized, transport-bridged traffic to a control plane behind it; the plane can also expose itself as an MCP server upstream of an external gateway when a team wants their wider agent infrastructure to dock to Harbor through one neutral entrypoint. The relationship is not zero-sum. A gateway buys you a clean network seam at the edge. A control plane buys you workspace-scoped ownership behind that seam. Many production setups end up with both — the gateway as a pure forwarder, the control plane as where workspace truth lives. Treat the choice between them as a question of layering, not of replacement.

Harbor’s positioning

Harbor is a Cloudflare-native control plane that covers several gateway-adjacent capabilities teams reach for — outbound MCP client pooling, OAuth metadata advertised at the standard .well-known/oauth-* endpoints, an AI bot allowlist surfaced through the local MCP stdio adapter, and a hosted entrypoint for agents that prefer to dock over a single connection — but it is not reducible to those functions. Discovery, credentials, server-side execution, orbit primitives, runs, and audit live in the plane. The wire is one layer of the product, not the product.

If you are evaluating gateway-shaped vendors against a control-plane shape, /compare has the per-vendor breakdown. The protected MCP endpoint and its OAuth metadata are documented in the security reference; production traffic lands at mcp.tryharbor.ai/mcp. If your team has already crossed the line where workspace ownership matters, connect a workspace and install your first MCP server against it.