How to Add and Govern MCP Servers in Claude Code
TL;DR
- To add an MCP server to Claude Code, register it with the
claude mcp addcommand or a project.mcp.jsonfile, choosing a local, project, or user scope for where it applies. - Native Claude Code configuration handles connecting a server; it does not enforce which teammates can use it, what a server may do, or how much it can spend.
- Bifrost, the open-source AI gateway by Maxim AI, is the control plane for MCP governance: virtual keys scope access, MCP tool filtering is deny-by-default, and six authentication types cover shared and per-user credentials.
- Bifrost Code Mode reduced input tokens by up to 92.8% and estimated cost by up to 92.2% in a 508-tool benchmark, so large MCP setups in Claude Code stay affordable.
- The Bifrost AI gateway defines the policy; Bifrost Edge (alpha) extends that policy to every machine so ungoverned MCP servers on developer laptops cannot bypass it.
Claude Code can connect to Model Context Protocol (MCP) servers to read files, query databases, call APIs, and run tools directly from the terminal. To add an MCP server to Claude Code, you register it with the claude mcp add command or a project .mcp.json file, and it becomes available to the agent on the next session. That local setup is straightforward for one developer; governing what those servers can do across a team is a separate problem. Bifrost, the open-source AI gateway built in Go by Maxim AI, adds the control plane that the setup step skips: virtual keys, deny-by-default tool access, per-server authentication, and audit logs for every MCP call Claude Code makes.
What Is an MCP Server in Claude Code?
An MCP server is an external process that exposes tools, resources, and prompts to an AI client over the Model Context Protocol, an open standard for connecting models to systems they can act on. In Claude Code, an MCP server turns the coding agent from a text generator into one that can search the web, read a database, open a Jira ticket, or edit files through a governed tool interface.
Claude Code speaks MCP over three transports: STDIO for local subprocesses, and HTTP or SSE for remote servers. The Model Context Protocol specification defines the message format, and Claude Code implements the client side. Once connected, a server's tools appear alongside Claude Code's built-in file and shell tools, which is why governance matters: an MCP server can read and write real systems.
How to Add an MCP Server to Claude Code
To add an MCP server to Claude Code, run claude mcp add <name> -- <command> for a local STDIO server, or claude mcp add --transport http <name> <url> for a remote server. Claude Code writes the configuration to the scope you choose, then loads the server's tools the next time it starts. The command is the fastest path from zero to a working tool connection.
A minimal local server registration looks like this:
# Local STDIO server (a filesystem or database tool)
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ./
# Remote HTTP server (a hosted API exposed over MCP)
claude mcp add --transport http github <https://api.githubcopilot.com/mcp/>
After adding a server, confirm it registered and inspect its tools before you rely on it.
Claude Code MCP Config Scopes
Claude Code MCP config lives in one of three scopes, and choosing the right one is the first governance decision you make. The scope decides who sees the server and whether it travels with the repository. Getting this wrong is how a personal API key ends up committed to the repo.
| Scope | Where it is stored | Who it applies to | Best for |
|---|---|---|---|
local |
Per-user project settings (not committed) | You, in this project only | Experiments and personal tools |
project |
.mcp.json at the repo root (committed) |
Everyone who clones the repo | Shared, reviewed team servers |
user |
Your global Claude Code settings | You, across all projects | Personal tools you use everywhere |
The project scope is the one that scales a tool to a team: the .mcp.json file is checked into version control, code-reviewed like any other change, and every teammate inherits the same server list. It answers "which servers should this project use," but it does not answer "which teammates may use them, with which credentials, and how much can they spend." That gap is where an MCP gateway centralizes tool access for the whole team.
Managing and Removing MCP Servers
Once servers are registered, claude mcp list shows every server and its connection status, claude mcp get <name> prints one server's configuration, and claude code remove mcp server (claude mcp remove <name>) unregisters one. Run claude mcp list first whenever a tool is missing; it surfaces the exact scope and transport in use.
These commands manage the connection, not the policy. Removing a server on your machine does nothing for the teammate who still has it configured, and the .mcp.json in the repo cannot express "allowed for the backend team, blocked for contractors." Fleet-wide control needs a layer above the local server list, which is what the Bifrost MCP gateway resource is built to provide.
The Governance Gap in Native MCP Setup
Native Claude Code MCP setup governs configuration, not behavior. It decides which servers are wired in and at what scope, but it does not authenticate callers individually, cap spend, restrict which tools a server exposes, or record an audit trail. For a solo developer that is enough; for a team running MCP servers against production systems, four gaps open at once.
- No per-user access control. A
projectscoped server in.mcp.jsonis available to everyone who clones the repo, with no way to allow it for some people and deny it for others. - No spend control. Nothing caps how many tokens or dollars an MCP-heavy Claude Code session consumes, and MCP tool catalogs are expensive to carry in context.
- No tool-level restriction. A connected server exposes all of its tools; native config cannot say "allow the read tools, block the write and delete tools."
- No audit trail. There is no central record of which user invoked which tool on which server, which is a problem for SOC 2, HIPAA, and internal review.
Anthropic's own Claude Code documentation warns that MCP servers can execute code and reach external systems, and recommends using only trusted servers. Governance is how "use trusted servers" becomes an enforced policy rather than a request.
What MCP Governance Requires
MCP governance is the practice of controlling who can use which MCP servers, which tools those servers may expose, what each caller is authorized and budgeted to do, and keeping an auditable record of every call. It is enforced at a control point between the AI client and the MCP servers, so policy applies regardless of what any developer configured locally.
A complete MCP governance layer provides five things:
- Identity and access control so each caller is a known entity, not an anonymous shared key.
- Authentication management so each server's credentials are stored and rotated centrally, not pasted into local config.
- Tool-level filtering so a server's dangerous tools can be withheld even when the server is allowed.
- Budgets and rate limits so an MCP-heavy session cannot run up unbounded cost.
- Audit logging so every tool call is attributable and reviewable.
The governance resource hub maps these requirements onto concrete gateway features, and the same controls apply whether the client is Claude Code, Cursor, or a custom agent.
How Bifrost Governs MCP Servers for Claude Code
Bifrost is the control plane that enforces MCP governance for Claude Code. It sits between the agent and every MCP server, connects to those servers as an MCP client over STDIO, HTTP, or SSE, and exposes a governed tool surface upward. Policy is defined once at the gateway and applied to every request, so no local .mcp.json grants access the gateway has not authorized. Four Bifrost mechanisms close the four native gaps directly.
Virtual keys are the primary governance entity. Each virtual key represents a user, team, or project, and carries its own access permissions, budgets, and rate limits. A contractor's key and a staff engineer's key can reach different MCP servers under the same gateway.
MCP tool filtering is deny-by-default. A virtual key with no MCP configuration gets no tools; you explicitly allow the clients and tools it may use, and Bifrost enforces that allow-list at inference time and again at tool-execution time. You can permit a server's read tools while blocking its write tools.
Authentication is centralized and typed. Bifrost supports six MCP authentication modes, from a shared admin credential to per-user OAuth, so credentials live in the gateway rather than in a developer's local files.
Budgets, rate limits, and audit logs apply to every call. Budget and rate-limit policies cap spend per key, and audit logs record every tool invocation for SOC 2, GDPR, HIPAA, and ISO 27001 review.
MCP Authentication Types
Bifrost separates authentication from transport, so each MCP server gets the credential model it needs regardless of how Claude Code reaches it. Server-level auth uses one shared credential the admin sets once; per-user auth binds a credential to each caller's identity and reuses it on later calls.
| Auth type | Who authenticates | When to use |
|---|---|---|
none |
No one | Public servers, local STDIO tools |
headers |
Admin, once | Shared API keys or bearer tokens |
per_user_headers |
Each user | Per-user API keys |
oauth |
Admin, once | A shared third-party service |
per_user_oauth |
Each user | Per-user services like GitHub or Notion |
token_exchange |
Each caller, every call | First-party servers that trust your identity provider |
For larger teams, Bifrost Enterprise adds MCP tool groups: reusable bundles of tools attachable to virtual keys, teams, customers, users, providers, or API keys, resolved at request time. Existing internal APIs can also be turned into governed MCP tools through federated auth with no glue code.
Point Claude Code at Bifrost
Claude Code routes through Bifrost by pointing its Anthropic-compatible base URL at the gateway and authenticating with a virtual key. The recommended method sets ANTHROPIC_AUTH_TOKEN to a Bifrost virtual key; Claude Code sends it as a bearer token, and Bifrost uses that key for routing, MCP tool filtering, budgets, and audit. No Anthropic account credentials are required on the developer's machine.
export ANTHROPIC_BASE_URL="<http://localhost:8080/anthropic>"
export ANTHROPIC_AUTH_TOKEN="your-bifrost-virtual-key"
claude
From that point, every model call and every MCP tool call Claude Code makes inherits the policy attached to the virtual key. The full setup, including header configuration for recent Claude Code versions, is documented in the Claude Code integration guide. Teams connecting Claude Code to many tools at once can follow the practical walkthrough for connecting Claude Code to an MCP gateway and for wiring multiple MCP servers through one gateway.
Bifrost can also run in reverse as a single MCP endpoint: in MCP gateway mode it aggregates every connected server behind one /mcp endpoint, so Claude Code connects to one governed server instead of a dozen unmanaged ones.
Controlling MCP Cost with Code Mode
Every MCP server a Claude Code session connects to adds its full tool catalog to the model's context on each request, and at eight to ten servers that catalog can consume most of the token budget before any work happens. Bifrost Code Mode removes that overhead by exposing four generic tools that let the model write sandboxed Python to orchestrate the rest, instead of loading every tool definition every turn.
The savings scale with tool count. In Bifrost's published benchmark across three rounds of increasing MCP footprint, Code Mode held or improved task pass rates while cutting resources sharply.
| MCP footprint | Input token change | Estimated cost change |
|---|---|---|
| 96 tools / 6 servers | -58.2% | -55.7% |
| 251 tools / 11 servers | -84.5% | -83.4% |
| 508 tools / 16 servers | -92.8% | -92.2% |
At roughly 500 tools, Code Mode reduced average input tokens per query by about 14x and ran around 40% faster. The full analysis is in the Bifrost MCP gateway benchmark writeup, and teams focused on cost can read how Bifrost cuts token costs in Claude Code specifically.
For a Claude Code team running many MCP servers, that keeps an agentic workflow affordable at scale. Bifrost adds only 11 microseconds of overhead per request at 5,000 requests per second, so this governance layer does not become a latency tax.
Extending Governance to Every Machine with Bifrost Edge
Gateway policy only governs the MCP traffic routed through the gateway. A developer can still run claude mcp add against an unapproved server and connect Claude Code straight to it, outside any policy. This is shadow AI: MCP servers on developer laptops that security teams cannot see, with no audit trail and no guardrails. The Bifrost AI gateway is the control plane; Bifrost Edge extends that control to every endpoint.
Bifrost Edge runs on each machine and routes all AI traffic, including the MCP servers Claude Code connects to, through Bifrost, so the same virtual keys, budgets, and guardrails apply on the laptop. Edge inventories the MCP servers configured inside each AI app across the fleet, so a team can finally answer "which MCP servers are running in Claude Code across our developers." Admins make per-server allow or deny decisions, and a denied server is blocked on the device, not merely discouraged.
Edge deploys fleet-wide through MDM platforms like Jamf, Intune, and Kandji, and is currently in alpha. The Edge overview covers app and MCP governance together, enforcing the same guardrails configured at the gateway.
Setup and Governance at a Glance
Native Claude Code setup and Bifrost governance are complementary layers, not alternatives. You still use claude mcp add and .mcp.json to connect servers; Bifrost decides what those connections are allowed to do.
| Concern | Native Claude Code | Bifrost governance |
|---|---|---|
| Connect a server | claude mcp add, .mcp.json |
Routed through the gateway |
| Per-user access | Not available | Virtual keys |
| Tool-level restriction | Not available | Deny-by-default filtering |
| Credential management | Local config | Six centralized auth types |
| Spend control | Not available | Budgets and rate limits |
| Audit trail | Not available | Immutable audit logs |
| Fleet visibility | Not available | Bifrost Edge inventory |
For enterprises running Claude Code in regulated environments, Bifrost supports in-VPC and on-prem deployment with role-based access control, so the governance layer runs inside your own infrastructure. Teams can also govern a single high-risk integration this way, such as when they govern Figma MCP access for Claude Code.
Frequently Asked Questions
Does Claude Code have access to MCP servers?
Yes. Claude Code is a full MCP client and connects to MCP servers over STDIO, HTTP, or SSE. You add a server with claude mcp add or a project .mcp.json file, and its tools become available to the agent. Bifrost sits between Claude Code and those servers to govern which tools each user can actually reach.
How to add MCP server in Claude Code?
Run claude mcp add <name> -- <command> for a local STDIO server, or claude mcp add --transport http <name> <url> for a remote one. Choose a scope: local for yourself, project to commit the server to .mcp.json for the team, or user to make it available across all your projects. Then run claude mcp list to confirm it connected.
Which MCP server is best for Claude Code?
The best MCP server depends on the task: filesystem and Git servers for code, a database server for data work, and issue-tracker servers like Jira or Linear for project workflows. Most teams connect several and govern them centrally, using Bifrost tool filtering to expose only the safe tools from each server per virtual key.
Which MCP server is most useful for Claude Code?
For most engineering teams, a filesystem or repository server and a database server deliver the most value, because they let Claude Code read real context and act on it. As the number of servers grows, Bifrost Code Mode keeps the token cost of carrying many tool catalogs low, cutting input tokens by up to 92.8% in large deployments.
How do you govern MCP servers across a Claude Code team?
Route Claude Code through Bifrost with a virtual key per user or team, define a deny-by-default tool allow-list per key, and centralize credentials in the gateway. Every tool call is then budgeted, rate-limited, and audit-logged. Bifrost Edge extends the same policy to endpoints so locally added servers cannot bypass governance.
Can you restrict which MCP tools Claude Code can use?
Yes. Bifrost MCP tool filtering is deny-by-default: a virtual key gets no MCP tools until you explicitly allow them, and you can allow a subset of a server's tools while blocking the rest. The allow-list is enforced both when tools are offered to the model and when a tool is executed, so a blocked tool cannot run even if it is requested.
Get Started with Governed MCP Servers in Claude Code
Adding an MCP server to Claude Code is a one-command task; governing those servers across a team is where Bifrost earns its place. Routing Claude Code through Bifrost gives you virtual keys, deny-by-default tool filtering, centralized authentication, budgets, and audit logs over every MCP call, without changing how developers add servers. To see how Bifrost governs MCP servers for Claude Code in your environment, book a demo with the Bifrost team.
