MCP Proxy vs MCP Gateway: What Each One Does
An MCP proxy and an MCP gateway both sit between AI clients and MCP servers, but they operate at different layers: one forwards JSON-RPC traffic, the other decides what each caller is permitted to do with it. The MCP proxy vs MCP gateway distinction becomes concrete once a team connects more than two or three MCP servers and has to answer which tools an agent can call, whose credentials it uses, and what those calls cost. Bifrost, the open-source AI gateway written in Go by Maxim AI, covers both roles: it connects outward to upstream MCP servers as a client and exposes a governed, per-caller tool surface inward as a server. This post separates the two terms and what each layer does.
What Is an MCP Proxy
An MCP proxy is a transport-level relay. It accepts Model Context Protocol traffic from a client, forwards JSON-RPC methods such as tools/list and tools/call to one or more upstream MCP servers, and returns the response unchanged. It may terminate TLS, attach a static header, or bridge a local STDIO server to HTTP for remote clients.
The Model Context Protocol specification defines those methods, and a proxy moves them without altering their meaning. That solves real connectivity problems, including making a subprocess-based server reachable over the network.
What a proxy typically handles:
- Forwarding JSON-RPC requests and responses between an MCP client and upstream MCP servers
- Transport bridging, most commonly STDIO to HTTP or SSE
- TLS termination and network-level access restrictions
- Static header or environment injection using a single shared credential
- HTTP-layer access logging
What it does not handle is the important part. A proxy has no model of the caller: a contractor's coding agent and a production service account arrive as connections carrying the same shared secret. It returns the same tools/list response to everyone, and it has no budget, no per-call record tied to a person, and no ability to deny a specific tool to a specific caller.
What Is an MCP Gateway
An MCP gateway is a policy and control plane for tool access. It aggregates many MCP servers behind a single endpoint, authenticates the caller, resolves that identity to policy, filters the visible tool surface per caller, brokers upstream credentials, controls execution, records every tool call, and tracks what tool use costs.
The functional shift is from forwarding to deciding. Where a proxy asks whether a request can reach a server, an MCP gateway asks whether this caller should see this tool, using whose credential, with what approval, at what cost, and where that is recorded. Aggregation is the visible feature; per-caller policy is what changes how a platform team operates, because tool visibility is computed per request rather than served from one static registry.
MCP Proxy vs MCP Gateway: Capability Comparison
The two layers overlap on transport and diverge on control. The table below compares a transport-level MCP proxy against an MCP gateway that resolves caller identity to governance policy on every request.
| Capability | MCP proxy | MCP gateway |
|---|---|---|
| Server aggregation | One upstream per process, or a static route table | One endpoint fronting many servers, merged tool registry |
| Caller identity | Not resolved; callers share one credential | Resolved per request from a virtual key, session, or SSO user |
| Per-caller tool filtering | None; the same tools/list for everyone |
Tool surface computed per caller, deny-by-default |
| Upstream auth brokering | Static header injection at best | Server-level and per-user credentials, OAuth with refresh |
| Execution approval | Pass-through; the client's call is executed | Explicit execution step, opt-in auto-execution per tool |
| Audit trail | HTTP access logs | Per-call records with caller, arguments, result, and cost |
| Token and cost control | None | Tool surface reduction, budgets per key, team, customer |
| Observability | Request counts and status codes | Tool call volume, top tools, cost histograms |
| Failure handling | Connection error returned to the caller | Health checks, backoff retry, disconnect state, reconnect |
Why MCP Tool Access Control Becomes Urgent at Scale
MCP tool access control stops being optional at roughly the third or fourth connected server. Three failure modes appear together: tool definitions crowd out the context window, upstream credentials get copied onto developer machines, and no one can produce an authoritative answer to which tools a given agent is allowed to call.
Tool definition token bloat. Every connected MCP server contributes its full tool schema to the model's context on each request. In a benchmark round covering 508 tools across 16 MCP servers, classic MCP averaged 1.15M input tokens per query, against roughly 83K tokens per query when definitions were loaded on demand instead, a cost profile documented in the MCP gateway benchmark writeup. A proxy forwards the whole catalog and cannot reduce it.
Credential sprawl. When each MCP server holds its own auth, developers end up storing a personal access token for every server in a local config file. The OWASP Top 10 for LLM Applications lists excessive agency and supply chain exposure among its primary risks for LLM systems, and scattered long-lived tokens for third-party tool servers sit at the intersection of the two. Revoking one person's access means finding every machine holding a copy.
No authoritative access answer. Security review asks which tools a production agent can invoke. With a proxy, the accurate answer is all of them, given the tool name. That does not survive a control review, and it does not scale to per-team separation.
MCP Gateway Architecture: How Bifrost Aggregates and Filters
Bifrost operates as both an MCP client and an MCP server. As a client it connects to external MCP servers over STDIO, HTTP, or SSE with automatic exponential-backoff retry. As a server it exposes the aggregated tool registry to clients such as Claude Desktop and Cursor over two endpoints: POST /mcp for JSON-RPC 2.0 tool discovery and execution, and GET /mcp for persistent SSE connections. MCP gateway mode runs in the Gateway deployment on v1.4.0-prerelease1 and above.
Caller identity arrives with the request. Clients authenticate with x-bf-vk, Authorization: Bearer vk_..., or X-Api-Key, and each virtual key receives its own MCP server view containing only the tools that key is allowed to use. A browser-based OAuth connect flow is supported as an alternative to header credentials. Because the tool list resolves from the presented key rather than from the endpoint, two teams pointing Claude Desktop at the same hostname see two different tool lists.
Tool visibility is resolved through three stacked filtering levels:
- Client configuration. The
tools_to_executefield on each MCP client sets the baseline.["*"]allows all tools from that client;[]or an omitted list denies everything. - Request headers. Per-request filters such as
x-bf-mcp-include-clientsandx-bf-mcp-include-toolsnarrow the surface for a single call. - Virtual key configuration. Per-key tool filtering enforces the allow-list at both inference time and tool execution time.
A tool must pass all applicable filters, and the default is deny. For larger deployments, MCP Tool Groups in Bifrost Enterprise define reusable bundles of tools that attach across six dimensions: virtual keys, teams, customers, users, LLM providers, and API keys. Matching groups merge and deduplicate at request time against an in-process index, so resolution adds no extra latency, and a master enable/disable switch revokes access without deleting attachments.
MCP Server Governance: Credentials, Execution, and Audit
MCP server governance answers the three questions a proxy leaves open: whose credential the upstream call uses, whether the call runs at all, and what record it leaves behind. Bifrost treats each as a separate configurable layer rather than a property of the network path.
Upstream authentication supports five types: none, static headers, OAuth 2.0 with automatic token refresh and PKCE, per-user OAuth, and per-user headers. Per-user modes matter for services like GitHub, Notion, or Sentry, where the call should carry the individual's identity rather than a shared service account. Credentials are stored against that identity and reused later, and MCP Sessions give administrators one row per identity and server to inspect, re-authenticate, edit, or revoke.
Execution control is security-first by default. Bifrost does not auto-execute tool calls: an LLM tool call is a suggestion, and running it requires an explicit call to POST /v1/mcp/tool/execute, leaving room for application-side policy checks or human approval. Agent Mode enables autonomous multi-step execution, and it is strictly opt-in through tools_to_auto_execute, configured per tool.
Cost control operates on the tool surface itself. Code Mode replaces 100-plus tool definitions with four meta-tools and lets the model write Python in a sandbox to orchestrate the rest, reducing input token usage by up to 92.8% and estimated cost by up to 92.2% against classic MCP; it is recommended at three or more connected servers. MCP tool logs then record each call, with tool-call volume histograms, cost histograms, and top tools by call count: the audit trail an enterprise deployment needs when a control review asks who called what.
Common Questions About MCP Proxy vs MCP Gateway
Is an MCP proxy enough for a small team?
For one or two internal MCP servers used by engineers who already share the same credentials, a proxy is a reasonable fit. The trigger for change is not team size but a second trust boundary: a contractor, a customer-facing agent, or a production service that should not see the same tools as a developer laptop.
Can an MCP gateway reduce token costs?
Yes, by controlling what reaches the model's context. Filtering removes tools a caller has no reason to call, and code-based orchestration replaces bulk tool definitions with on-demand loading, cutting input tokens by up to 92.8% in large MCP gateway deployments. A proxy forwards the full catalog by design.
Does an MCP gateway replace per-server authentication?
No, it brokers it. Upstream MCP servers keep their own auth requirements; the gateway holds the credential, refreshes OAuth tokens, and binds per-user credentials to the caller's identity, so developers stop storing long-lived tokens locally.
When should a team move from proxy to gateway?
The practical thresholds are three or more connected MCP servers, more than one consuming team, any tool with write access to a production system, or a requirement to state which tools an agent can invoke. Meeting one of these makes per-caller policy a functional requirement rather than a preference.
Getting Started with Bifrost as an MCP Gateway
The MCP proxy vs MCP gateway choice decides where tool policy lives: in application code and a set of shared secrets, or in one control plane in front of every MCP server. Bifrost is built for the second pattern, with per-caller tool filtering, brokered upstream credentials, explicit execution control, and full tool-call logging in a self-hosted gateway.
To see how Bifrost governs MCP tool access across your teams and agents, book a demo with the Bifrost team.
