Claude Code becomes significantly more powerful when you connect it to the systems developers actually work with: GitHub repositories, databases, documentation, internal APIs, file systems, observability platforms, and other engineering tools. The Model Context Protocol (MCP) makes these integrations possible through a common interface. Instead of building a custom integration for every AI application and every tool, teams can expose capabilities through MCP servers and make them available to compatible AI clients. That works extremely well when you have a handful of tools. At enterprise scale, however, the architecture starts to become more complicated. A development team may need multiple MCP servers, different credentials for different developers, controls over which tools each team can access, visibility into tool usage, and a way to prevent hundreds of tool definitions from consuming the model's context. This is where an MCP gateway becomes useful. Bifrost is an open-source AI gateway that can sit between applications such as Claude Code and the underlying LLM providers and MCP servers. Its GitHub repository and documentation cover provider routing, MCP aggregation, virtual keys, governance, observability, and other capabilities designed for running AI infrastructure at a larger scale. In this article, we'll look at why an MCP gateway becomes useful for enterprise Claude Code deployments, how Bifrost approaches the problem, and where features such as MCP aggregation and Code Mode can make a practical difference.
Claude Code + MCP Is Powerful - Until the Number of Integrations Grows
Consider a developer using Claude Code with only three MCP servers:
This is straightforward. Claude Code can discover the tools exposed by each server and use the appropriate one when required. But enterprise environments rarely stop at three integrations. A mature engineering organization might eventually connect GitHub, Jira, Slack, PostgreSQL, internal documentation, cloud infrastructure, observability, file systems, CI/CD systems, internal APIs, security tooling, and search services. Different departments may need completely different combinations. At that point, the architecture can start looking more like this:
This creates several operational questions. How do we manage all these connections? How do we control which developer can use which tools? Where do credentials live? How do we observe MCP activity? And what happens to the LLM context when the number of available tools becomes very large? The challenge is no longer simply connecting Claude Code to MCP; it becomes an infrastructure and governance problem.
Introducing an MCP Gateway
An MCP gateway adds an abstraction layer between the AI client and the MCP ecosystem. Instead of configuring every MCP server independently in every Claude Code installation, the architecture becomes:
From Claude Code's perspective, Bifrost can appear as a single MCP server. Behind that endpoint, Bifrost can aggregate the MCP servers configured by the organization. Instead of developers maintaining numerous MCP entries, Claude Code can connect to a single endpoint: /mcp
This is one of the most immediately useful aspects of using Bifrost with Claude Code. According to Bifrost's Claude Code integration documentation, configured MCP tools can be aggregated behind the /mcp endpoint while Bifrost provides centralized governance, observability and per-virtual-key tool filtering. That moves MCP management away from individual developer machines and toward centrally managed infrastructure.
Connecting Claude Code to Bifrost
Bifrost supports adding its gateway directly as an MCP server in Claude Code. See Bifrost's Claude Code documentation for the integration details. A typical configuration uses Claude Code's MCP CLI:
claude mcp add --transport http bifrost http://localhost:8080/mcp \
--header "Authorization: Bearer your-virtual-key" \
--scope user
Alternatively, the MCP server can be configured through .mcp.json or ~/.claude.json:
{
"mcpServers": {
"bifrost": {
"type": "http",
"url": "http://localhost:8080/mcp",
"headers": {
"Authorization": "Bearer your-virtual-key"
}
}
}
}
For a production deployment, localhost would normally be replaced with the organization's hosted Bifrost endpoint. Once configured, Claude Code sees Bifrost as an MCP server while Bifrost manages access to the underlying MCP infrastructure. Inside Claude Code, the /mcp command can be used to verify the connection and inspect the available tool count.
Why Virtual Keys Matter in Enterprise Environments
A shared gateway alone doesn't solve enterprise access control. Imagine an organization with three teams: Engineering, Finance, and Support. Engineering might require access to GitHub, CI/CD, infrastructure, and documentation. Finance may require a financial database, reporting APIs, and internal documents. Support might require CRM, documentation, and a ticketing system. Giving every developer unrestricted access to every MCP tool would be a poor security model. Bifrost uses Virtual Keys (VKs) as one mechanism for controlling access. Claude Code can authenticate to Bifrost using a virtual key, for example through: ANTHROPIC_AUTH_TOKEN or through the authorization header used for the MCP gateway. The gateway can then use the caller's identity to determine which MCP configurations and tools should be exposed. Conceptually, Developer A can authenticate with Virtual Key A and receive access to GitHub, Documentation, and CI/CD, while Developer B can authenticate with Virtual Key B and receive access to Documentation and Reporting.
This gives organizations a cleaner control point than distributing every underlying service credential directly to each developer. It also means the same Bifrost deployment can expose different tool sets to different callers.
Bifrost Is More Than an MCP Gateway
Another useful part of the architecture is that Bifrost can also operate as the LLM gateway. Claude Code normally communicates with Anthropic's API. When Bifrost is introduced into the inference path, the architecture can instead look like:
Bifrost's Claude Code integration supports routing Claude Code inference through its Anthropic-compatible endpoint. A configuration can use environment variables similar to:
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "your-bifrost-virtual-key",
"ANTHROPIC_BASE_URL": "https://bifrost.example.com/anthropic"
}
}
The important architectural point is not merely changing an API URL. The gateway becomes a common control plane between coding agents and model providers. For enterprises operating multiple AI applications, this can make provider configuration, authentication, budgets and observability easier to centralize rather than implementing those capabilities separately in every application.
The Hidden Scaling Problem: MCP Tool Definitions Consume Context
Centralized management solves one problem, but large MCP deployments introduce another. Context size. When MCP tools are exposed conventionally, their definitions need to be available to the model so it understands what tools exist and how to call them. With five or ten tools, that overhead may be relatively small. But consider an environment with 8 MCP servers and 150+ tools, or a larger deployment with 16 MCP servers and 500+ tools. Now the model may be receiving a substantial tool catalogue alongside the actual developer request. And that catalogue can be repeated across multiple model interactions. This means tokens are being spent describing tools that may have nothing to do with the current task. For enterprise MCP deployments, reducing this overhead can become important for both cost and latency. Bifrost addresses this through a feature called Code Mode.
Bifrost Code Mode
The idea behind Code Mode is surprisingly simple. Instead of exposing hundreds of MCP tools directly to the model, Bifrost exposes a small set of generic meta-tools. The current implementation provides four: listToolFiles, readToolFile, getToolDocs, and executeToolCode.
These allow the model to discover available MCP capabilities when they are actually needed. Conceptually, instead of loading a long catalogue of individual tool definitions into the LLM context, Code Mode keeps a small set of meta-tools available and lets the model discover the specific capabilities it needs on demand.
The model can first discover the relevant server, inspect the signatures it needs, and then execute the workflow. This significantly changes how MCP deployments scale as the number of tools and integrations grows.
Code Instead of Repeated Tool Calls
Code Mode goes further than dynamically loading tool definitions. The model can write Python-like code executed through Bifrost's sandboxed Starlark environment to orchestrate multiple MCP tools. Imagine a request such as:
Find all open critical issues assigned to my team, check the related pull requests, and return the ones whose CI pipelines are failing.
A conventional agent may need a sequence of model round trips: call the issue tool, return the result to the LLM, call the PR tool, return that result, call the CI tool, return that result, and finally produce the answer.
Each step potentially creates another model round trip. With Code Mode, more of the orchestration can happen inside the execution environment:
This is particularly interesting for workflows involving loops, filtering, conditionals, and several MCP servers. The model does not necessarily need to process every intermediate result itself.
What Do Bifrost's Benchmarks Show?
This is where the token-reduction numbers associated with Bifrost need some context. Bifrost has published controlled benchmarks comparing classic MCP usage with Code Mode across progressively larger MCP configurations. Their documented results include:
| MCP footprint | Classic input tokens | Code Mode input tokens | Reduction |
|---|---|---|---|
| 96 tools / 6 servers | 19.9M | 8.3M | 58.2% |
| 251 tools / 11 servers | 35.7M | 5.5M | 84.5% |
| 508 tools / 16 servers | 75.1M | 5.4M | 92.8% |
In Bifrost's largest documented benchmark, involving 508 tools across 16 MCP servers, Code Mode reduced input-token usage by 92.8% and the estimated cost by 92.2%. The reported pass rate remained 100% in that round. That is an impressive result, but the context matters. It would be misleading to say:
"Bifrost always reduces Claude Code token usage by 92.8%."
It doesn't. The percentage comes from Bifrost's specific large-scale benchmark. Their smaller test with 96 tools showed a 58.2% input-token reduction instead. The takeaway is therefore more useful than the headline number: Code Mode's benefits become increasingly significant as the number of MCP servers and tools grows. For an individual developer using one small MCP server, this may not be a compelling reason to change architecture. For an enterprise exposing hundreds of tools, it can be.
When Should You Use Code Mode?
Bifrost itself recommends considering Code Mode when there are three or more MCP servers, complex multi-step workflows, token-cost or latency concerns, or tools that frequently interact with one another. Classic MCP can still make sense for one or two small servers and simple direct tool calls. That distinction is important. Architecture should match the problem. If your entire setup is Claude Code connected to a single GitHub MCP server, introducing additional infrastructure purely for token optimization may be unnecessary.
But if the environment is Claude Code connected to 10+ enterprise MCP integrations with hundreds of tools, the economics and operational complexity are different.
Bifrost also supports mixing the approaches: heavier MCP servers can use Code Mode while smaller utilities remain available as conventional tools.
Centralized Observability
Another issue appears once AI coding agents become part of daily engineering workflows: What are they actually doing? When integrations are independently configured across developer machines, understanding tool usage across the organization becomes difficult. A gateway creates a central observation point:
This becomes increasingly valuable as organizations move from a few AI experiments to dozens or hundreds of developers using AI agents. Observability isn't just useful for debugging. It can help answer operational questions such as:
- Which integrations are actually being used?
- Which models or providers are handling traffic?
- Where is AI-related usage coming from?
- Which MCP calls are failing?
- Are particular workflows generating unusually high usage?
Centralization gives platform teams somewhere to investigate those questions.
A More Practical Enterprise Architecture
Putting these pieces together gives us a more scalable Claude Code architecture.
This separation is useful. Claude Code remains the developer-facing agent. MCP remains the integration protocol. Bifrost becomes infrastructure between the developer-facing agent and the services behind it. That allows the platform team to change infrastructure policies without requiring every developer to manually reconfigure a long list of integrations.
Things to Consider Before Adopting an MCP Gateway
Adding a gateway is not free. It introduces another infrastructure component that needs to be deployed, configured, secured, monitored, and upgraded. There are also some Bifrost-specific operational details worth understanding. For example, when Claude Code routes inference through Bifrost and connects to Bifrost's /mcp endpoint, the same MCP tool could potentially appear through both paths. Bifrost includes Claude Code-specific deduplication, but its documentation recommends disabling automatic MCP tool injection for this configuration so the inference and MCP paths remain clearly separated. Authentication configuration also matters. Organizations using global MCPs, per-user OAuth, per-user headers, virtual keys, or enterprise SSO will need to choose an identity model appropriate for their environment. And Code Mode itself should be adopted deliberately. Because it changes tool orchestration from individual model-driven calls to sandboxed code execution, teams should understand the security and operational implications before enabling it broadly. A gateway is therefore most valuable when the problems it solves, scale, governance, observability, provider abstraction, and tool proliferation, justify the additional infrastructure.
Is Bifrost a Good MCP Gateway for Claude Code?
For a developer experimenting with one or two MCP servers, direct configuration may be perfectly adequate. The Bifrost architecture becomes much more interesting when Claude Code is being deployed across teams. Its strongest proposition isn't simply:
"Connect Claude Code to MCP."
Claude Code can already do that. The more interesting proposition is:
Put a manageable infrastructure layer between many Claude Code users and a growing ecosystem of models, MCP servers, credentials and tools.
Bifrost combines several capabilities relevant to that problem:
- a centralized MCP endpoint,
- MCP aggregation,
- virtual-key-based access control,
- model/provider routing,
- observability,
- centralized governance,
- and Code Mode for reducing the context overhead of large tool catalogues.
The Code Mode benchmarks are especially interesting for large deployments. Bifrost's published tests show that the token savings increase substantially as the MCP footprint grows, reaching a 92.8% input-token reduction in its largest documented 508-tool benchmark. That's not a universal performance guarantee, but it demonstrates why MCP architecture deserves attention as tool counts move from tens to hundreds.
Final Thoughts
MCP makes it remarkably easy to extend AI coding agents. The next challenge is operating those integrations at scale. A developer can manage three MCP servers. An enterprise platform team managing hundreds of developers, many MCP servers, hundreds of tools, multiple model providers, different permissions and significant AI spending faces a very different problem. That's the layer where an MCP gateway starts making sense. Bifrost's approach is particularly interesting because it combines the MCP gateway and LLM gateway concepts rather than treating them as completely separate infrastructure. And Code Mode addresses a problem that becomes increasingly visible as MCP adoption grows: the cost of telling the model about every available tool on every request. If you're already using Claude Code with several MCP servers, or you're designing an internal AI development platform that eventually will, the architecture is worth testing with your own workloads. Start with your actual tool set. Measure token usage. Measure latency. Look at how permissions need to work across teams. Then compare classic MCP with the gateway approach. The most useful question isn't whether every Claude Code user needs an MCP gateway. It's whether your MCP environment has grown complicated enough that you shouldn't be managing it one developer configuration at a time. For larger Claude Code deployments, that's exactly the problem Bifrost is trying to solve.
Top comments (0)