MCP Gateway: The Control Plane for MCP Servers
TL;DR
- An MCP gateway is the control plane that governs, secures, and cost-optimizes every Model Context Protocol server behind one endpoint.
- Bifrost connects to MCP servers over STDIO, HTTP, or SSE and exposes every permitted tool through a single
/mcpendpoint. - Bifrost supports six MCP authentication types, and virtual keys receive no MCP tools unless an admin grants them or marks a client Allow by Default.
- Code Mode cut input tokens by up to 92.8% and estimated cost by up to 92.2% at 508 tools across 16 servers.
- Bifrost never auto-executes tool calls unless an admin marks the tool as auto-executable in Agent Mode.
An MCP gateway is a single control plane that sits between AI models and the Model Context Protocol servers they call, deciding which tools are exposed, how they authenticate, and what they cost. Many teams connect MCP servers faster than they add central authentication, access control, or an audit trail, and that traffic runs ungoverned. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the MCP control plane enterprise teams use to route, govern, and secure MCP traffic across every model and environment from one endpoint. This post covers what that control plane does, why Model Context Protocol servers need one, and how Bifrost provides it; for a broader primer, see the guide to MCP gateways for production AI agents.
What Is an MCP Gateway?
An MCP gateway is a control layer that aggregates multiple Model Context Protocol servers behind one governed endpoint, so AI models reach every tool through a single connection instead of many direct ones. The gateway acts as an MCP client to the upstream servers and as an MCP server to the AI applications that consume those tools.
The Model Context Protocol is an open standard that lets AI models discover and execute external tools at runtime, from filesystem access and web search to database queries and custom business logic. Each capability lives in a separate MCP server. Without a gateway, every AI client connects to every server directly, and each connection carries its own credentials, tool permissions, and failure modes.
Bifrost consolidates those connections. Configured as an MCP client and server, it connects to any MCP-compatible server, then exposes the combined tool registry to clients like Claude Desktop and Cursor through one endpoint.
What is the difference between an MCP server and an MCP gateway?
An MCP server exposes one set of tools, for example a GitHub server or a Postgres server. A gateway sits in front of many MCP servers, aggregating their tools and enforcing authentication, access control, and observability across all of them. The differences between an MCP proxy, a server, and a gateway come down to how much policy each layer enforces.
Do I need a gateway for a single MCP server?
For one or two small servers, direct connections are workable. Once an organization runs several MCP servers across multiple teams and agents, a gateway becomes the practical way to apply consistent auth, tool governance, and cost control.
| Concern | Direct MCP server connections | MCP gateway control plane |
|---|---|---|
| Credentials | Stored and rotated per server, per client | Configured once per server at the gateway |
| Tool exposure | Every tool the server publishes | Allow-list per virtual key, deny-by-default |
| Client endpoints | One connection per server | One /mcp endpoint for all permitted tools |
| Token footprint | Every tool definition in every request | Code Mode loads tool stubs on demand |
| Audit and metrics | Scattered across server logs, if any | Central MCP logs, Prometheus metrics, audit logs |
Why MCP Servers Need a Control Plane
Model Context Protocol servers need a control plane because ungoverned tool access is now a documented security and cost problem. The OWASP MCP Top 10, the first OWASP framework dedicated to MCP risk, lists insufficient authentication and authorization, privilege escalation via scope creep, lack of audit and telemetry, and shadow MCP servers among its ten categories.
The gaps compound as server count grows:
- No central authentication. Each MCP server manages its own credentials, so there is no single place to rotate keys or revoke access.
- Over-privileged tools. Servers often expose every tool to every caller, giving agents the ability to delete or export data they never need.
- Shadow MCP servers. Teams spin up unapproved servers for convenience, and those connections sit outside any security review.
- No audit trail. When a tool call modifies data, there is often no immutable record of who invoked it and when.
- Runaway token costs. Connecting many servers pushes hundreds of tool definitions into every request, inflating input tokens and cost.
These are not edge cases. The NSA has published guidance on securing MCP deployments, and Cycode's 2026 State of Product Security report found that 81% of organizations lack full visibility into how AI is used across their software lifecycle. A control plane closes these gaps by routing every MCP connection through one governed layer, the role Bifrost as an MCP control plane fills.
Teams in finance and healthcare face the strictest version of this problem, covered in the MCP gateway control guide for regulated industries.
How Bifrost Works as an MCP Gateway
Bifrost fills this role by acting as both an MCP client and an MCP server at the same time. Bifrost connects outward to your tool servers and presents inward as a single MCP endpoint that any compatible client can call, so a new server becomes available to every authorized client without changing client configuration.
The connection model is straightforward:
- Connect to servers. Bifrost connects to MCP servers over STDIO for local tools, and HTTP or SSE for remote and streaming servers.
- Aggregate the registry. Every tool from every connected server is merged into one registry.
- Expose one endpoint. Bifrost exposes that registry as an MCP server at a single
/mcpendpoint, using JSON-RPC 2.0 for tool discovery and execution and SSE for persistent connections.
Clients such as Claude Desktop, Cursor, and custom applications point at that one endpoint and receive the aggregated tools, filtered by policy. Every request to /mcp is scoped to what its credentials allow, so different clients see different tools from the same endpoint, and clients can authenticate with header credentials or a browser-based OAuth connect flow. Used as an MCP gateway, Bifrost turns many scattered tool connections into one governed control plane, the same design pattern that lets the Bifrost AI gateway route across 25+ providers and 10,000+ models with 11 microseconds of overhead per request at 5,000 RPS.
Centralizing MCP Authentication and Access Control
Bifrost centralizes MCP authentication and access control so every tool call passes through one policy layer. Authentication is configured per server, and tool exposure is controlled per key, which replaces scattered per-server credentials with a single enforcement point.
Bifrost supports six MCP authentication types:
| Auth type | Who authenticates | When to use |
|---|---|---|
| None | No one | Public MCP servers and local STDIO tools that need no credential |
| Headers | Admin, once | A single shared API key or bearer token |
| Per-user headers | Each end user | Per-user API keys or tokens keyed to a person |
| OAuth 2.0 | Admin, once | A shared OAuth credential for a service the whole team uses |
| Per-user OAuth | Each end user | Individual accounts on services like Notion, GitHub, or Sentry |
| Token exchange (enterprise) | Each caller, every call | Internal MCP servers that trust your identity provider; the exchanged token is never stored |
Per-user auth types apply to HTTP and SSE connections. STDIO servers inherit their environment from the spawned subprocess and have no per-call auth model.
Access control runs through virtual keys, the primary governance entity. MCP tool filtering is deny-by-default: a virtual key with no MCP configuration receives no tools except from clients an admin marks as Allow by Default, and admins grant a strict allow-list per key.
Tool filtering also stacks at the client and request-header levels, so a tool must pass every applicable filter.
The patterns behind these controls are covered in MCP tool governance: filtering, allowlisting, and access control and tool-level MCP RBAC for production agents.
For larger organizations, Virtual MCPs (previously called MCP tool groups) bundle curated tool subsets, serve each bundle at its own /mcp/<slug> path, and attach it to virtual keys. Bifrost Enterprise extends Virtual MCPs with access-profile grants, data access control, and project assignment.
Regulated teams can pair this with enterprise deployment options including RBAC, SSO, and in-VPC isolation.
Cutting MCP Token Costs at Scale
Connecting many MCP servers inflates token costs because every request carries all tool definitions in context. At five or more servers, that can mean 150 or more tool schemas in every call, and the model spends much of its budget reading catalogs instead of working. The Bifrost AI gateway addresses this with Code Mode.
Code Mode exposes just four generic meta-tools to the model: listToolFiles, readToolFile, getToolDocs, and executeToolCode. Instead of receiving every tool definition, the model writes Python (Starlark) in a sandbox to discover, load, and orchestrate tools on demand, and only the compact final result returns to the model. In sustained benchmarks, this reduced input token usage by up to 92.8% and estimated cost by up to 92.2%, with around 40% faster execution in large MCP deployments.
| Round | MCP footprint | Input token change | Cost change |
|---|---|---|---|
| 1 | 96 tools / 6 servers | -58.2% | -55.7% |
| 2 | 251 tools / 11 servers | -84.5% | -83.4% |
| 3 | 508 tools / 16 servers | -92.8% | -92.2% |
The savings scale with tool count: at around 500 tools across 16 servers, average input tokens per query dropped roughly 14x, from 1.15M to 83K. Code Mode is enabled per MCP client, so teams can route heavy servers (web search, documents, databases) through it and keep small utilities as direct tools; the Code Mode explainer walks through that setup. The full method and results are covered in the MCP gateway benchmark writeup, and the same MCP control layer that governs access also delivers this cost reduction. Cost governance and access governance run through the same control plane, not two separate systems.
Auditing and Observing MCP Traffic
A control plane is complete only when every tool call is recorded and safe by default. Bifrost does not auto-execute tool calls: by default, tool calls returned by a model are treated as suggestions, and tool execution requires an explicit, separate API call from your application. Agent Mode enables autonomous execution only for tools an admin lists in tools_to_auto_execute, so automation is opt-in rather than the default.
Bifrost records operational and administrative activity in separate layers:
- MCP logs. The built-in observability layer records MCP tool calls alongside LLM requests, with captured request headers stored as metadata.
- Prometheus metrics. The telemetry plugin exposes
bifrost_mcp_client_operation_duration_seconds, labeled by MCP client, tool name, and error type, so call volume, latency, and failures per tool are queryable. - Audit logs. Audit logs record administrative activity with HMAC-signed entries, configurable retention, and export to JSON, JSON Lines, or Syslog.
OpenTelemetry tracing sends traces to existing OTLP collectors, placing gateway traffic in the same monitoring stack as the rest of your AI infrastructure. Together, these give platform teams the visibility that direct, per-server MCP connections cannot provide; auditing every AI tool call through an MCP gateway covers the observability setup in more depth.
Frequently Asked Questions
What is an MCP control plane?
An MCP control plane is the governed layer that decides which Model Context Protocol tools each caller can see, how every upstream server authenticates, and how tool calls are logged and metered. An MCP gateway such as Bifrost implements the control plane by routing all MCP traffic through one endpoint instead of letting each client connect to each server directly.
How do MCP servers authenticate through Bifrost?
Each MCP server connection in Bifrost carries its own auth type: none, headers, per-user headers, OAuth 2.0, per-user OAuth, or enterprise token exchange. Admin-level types use one shared credential, while per-user types store each end user's credential against their virtual key, signed-in identity, or session and reuse it on later calls.
How does an MCP gateway reduce token costs?
An MCP gateway reduces token costs by stopping every tool definition from being sent with every request. Bifrost Code Mode replaces hundreds of tool schemas with four meta-tools and runs orchestration in a Starlark sandbox. In benchmarks, input tokens fell 58.2% at 96 tools and 92.8% at 508 tools, with estimated cost down 55.7% and 92.2% respectively.
Can an MCP gateway stop agents from running destructive tools?
Yes. Bifrost treats model-returned tool calls as suggestions that your application executes explicitly, and Agent Mode auto-executes only tools listed in tools_to_auto_execute. Combined with deny-by-default tool filtering on virtual keys, a destructive tool such as a delete or export operation stays unavailable unless an admin grants it to a specific key.
Is Bifrost an open-source MCP gateway?
Yes. Bifrost is open source, written in Go, and published on GitHub by Maxim AI. The MCP gateway features in open-source Bifrost include server connections, tool filtering, Code Mode, Agent Mode, and Virtual MCPs. Bifrost Enterprise adds capabilities such as audit logs, token exchange authentication, RBAC, access profiles, and in-VPC deployment for regulated environments.
Build Your MCP Control Plane with Bifrost
An MCP gateway turns sprawling, ungoverned Model Context Protocol connections into one control plane with central authentication, per-key access control, cost governance, and full auditability. The open-source Bifrost gateway provides that layer as a high-performance foundation that scales from a single agent to enterprise fleets, and pairs MCP governance with the broader Bifrost resource library for platform teams.
Teams evaluating options can compare approaches in the primer on how an MCP gateway centralizes tool access and the Bifrost governance overview. To see how Bifrost can govern your MCP servers, book a demo with the Bifrost team.
