Open-source AI gateway that can connect to downstream MCP servers and expose their aggregated tools through a single HTTP or SSE MCP endpoint for Claude Desktop, Cursor, and other MCP clients.
Bifrost can expose all selected downstream MCP tools through one `/mcp` gateway endpoint, so treat the endpoint like an access layer for every connected tool., The docs state that default LLM tool calls are suggestions until an explicit tool execution API call is made, but agent mode can enable configured automatic execution., Gateway-mode auto-approval is controlled by the external MCP host, such as Claude Desktop, Cursor, Cline, or a custom client, not by Bifrost's `tools_to_auto_execute` setting., Stdio connections spawn local commands inside the Bifrost runtime; Docker deployments need images that include the requested executables., Use virtual keys, per-tool allowlists, auth headers, OAuth, per-user credentials, and network controls to limit which clients can reach high-impact tools.
Privacy notes
Bifrost may process provider prompts, model responses, MCP tool names, tool arguments, tool results, headers, virtual keys, OAuth tokens, per-user credentials, logs, traces, metrics, and downstream server metadata., Per-user auth stores credentials against a signed-in user, virtual key, or session identity; review credential lifecycle, revocation, and orphaned-session behavior., Logs, config stores, provider settings, MCP sessions, and gateway analytics can contain sensitive operational or user data., Keep real provider keys, virtual keys, OAuth secrets, MCP endpoint URLs, and upstream service credentials in environment variables or secret stores, not committed config.
Author
maximhq
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-06
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
63
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Needs review
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
No reviewed flag detected in metadata.
Pending
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
5 safety and 4 privacy notes across 3 risk areas. Review closely: credentials & tokens, network access.
3 areas
SafetyNetwork accessBifrost can expose all selected downstream MCP tools through one `/mcp` gateway endpoint, so treat the endpoint like an access layer for every connected tool.
SafetyNetwork accessThe docs state that default LLM tool calls are suggestions until an explicit tool execution API call is made, but agent mode can enable configured automatic execution.
SafetyExecution & processesGateway-mode auto-approval is controlled by the external MCP host, such as Claude Desktop, Cursor, Cline, or a custom client, not by Bifrost's `tools_to_auto_execute` setting.
SafetyNetwork accessStdio connections spawn local commands inside the Bifrost runtime; Docker deployments need images that include the requested executables.
SafetyCredentials & tokensUse virtual keys, per-tool allowlists, auth headers, OAuth, per-user credentials, and network controls to limit which clients can reach high-impact tools.
PrivacyCredentials & tokensBifrost may process provider prompts, model responses, MCP tool names, tool arguments, tool results, headers, virtual keys, OAuth tokens, per-user credentials, logs, traces, metrics, and downstream server metadata.
PrivacyCredentials & tokensPer-user auth stores credentials against a signed-in user, virtual key, or session identity; review credential lifecycle, revocation, and orphaned-session behavior.
PrivacyCredentials & tokensLogs, config stores, provider settings, MCP sessions, and gateway analytics can contain sensitive operational or user data.
PrivacyCredentials & tokensKeep real provider keys, virtual keys, OAuth secrets, MCP endpoint URLs, and upstream service credentials in environment variables or secret stores, not committed config.
Safety notes
Bifrost can expose all selected downstream MCP tools through one `/mcp` gateway endpoint, so treat the endpoint like an access layer for every connected tool.
The docs state that default LLM tool calls are suggestions until an explicit tool execution API call is made, but agent mode can enable configured automatic execution.
Gateway-mode auto-approval is controlled by the external MCP host, such as Claude Desktop, Cursor, Cline, or a custom client, not by Bifrost's `tools_to_auto_execute` setting.
Stdio connections spawn local commands inside the Bifrost runtime; Docker deployments need images that include the requested executables.
Use virtual keys, per-tool allowlists, auth headers, OAuth, per-user credentials, and network controls to limit which clients can reach high-impact tools.
Privacy notes
Bifrost may process provider prompts, model responses, MCP tool names, tool arguments, tool results, headers, virtual keys, OAuth tokens, per-user credentials, logs, traces, metrics, and downstream server metadata.
Per-user auth stores credentials against a signed-in user, virtual key, or session identity; review credential lifecycle, revocation, and orphaned-session behavior.
Logs, config stores, provider settings, MCP sessions, and gateway analytics can contain sensitive operational or user data.
Keep real provider keys, virtual keys, OAuth secrets, MCP endpoint URLs, and upstream service credentials in environment variables or secret stores, not committed config.
Prerequisites
Node.js with `npx`, Docker, or another supported Bifrost Gateway deployment path.
Bifrost Gateway version `v1.4.0-prerelease1` or newer for MCP gateway mode.
Downstream MCP server commands or HTTP/SSE endpoint URLs prepared before registering clients.
Provider API keys, virtual keys, gateway auth settings, and governance policies reviewed before sharing the endpoint.
Network, TLS, storage, log retention, and secret management decisions made before exposing Bifrost outside a trusted environment.
Bifrost is an Apache-licensed AI gateway from Maxim that includes MCP client
and MCP server capabilities. In gateway deployments, it can connect to
downstream MCP servers over stdio, HTTP, or SSE, discover their tools, and
expose the selected tools through a single /mcp endpoint for Claude Desktop,
Cursor, Cline, and other MCP-compatible clients.
The MCP docs distinguish two common modes. Bifrost can act as an MCP client for
external servers, and it can also act as an MCP server that publishes an
aggregated tool registry to external MCP hosts. The gateway endpoint supports
JSON-RPC POST requests and SSE connections, with optional virtual-key
authentication and per-key tool filtering.
These sources were reviewed on 2026-06-06. Prefer the live repository,
MCP overview, MCP gateway docs, connection docs, auth docs, Docker image page,
and license file for current version requirements, deployment options, auth
behavior, and MCP endpoint details.
Features
Connect Bifrost to downstream MCP servers over stdio, HTTP, or SSE.
Expose aggregated MCP tools through Bifrost's /mcp gateway endpoint.
Support JSON-RPC POST and SSE gateway connections for compatible MCP clients.
Configure virtual-key-specific MCP servers and per-key tool allowlists.
Use server-level headers, OAuth, per-user OAuth, or per-user header auth for HTTP and SSE upstreams.
Manage downstream MCP clients through the web UI, API, or config.json.
Inspect connected MCP tools and enable or disable selected tools.
Store per-user MCP credentials against user, virtual-key, or session identities.
Combine MCP routing with Bifrost's provider gateway, logging, metrics, governance, and config stores.
Register in-process custom tools when embedding Bifrost as a Go SDK application.
Installation
The README documents npx and Docker gateway startup paths. The shortest local
start is:
npx -y @maximhq/bifrost
After the gateway starts, register downstream MCP clients through the MCP
Gateway UI, the management API, or the mcp.client_configs section in
config.json. Use environment references for sensitive connection strings and
secrets.
For external MCP clients, configure the client to connect to the Bifrost MCP
gateway endpoint and include any required virtual-key auth header:
The upstream docs note that Bifrost's MCP gateway feature requires the Gateway
deployment and v1.4.0-prerelease1 or newer.
Use Cases
Give Claude one governed endpoint for a curated group of internal MCP tools.
Publish separate MCP tool sets for production, development, admin, or analyst virtual keys.
Connect local stdio tools, remote HTTP tools, and SSE tools behind one gateway.
Require per-user OAuth or header credentials before a downstream tool executes.
Use Bifrost's provider gateway and MCP gateway together in agent workflows.
Audit MCP traffic through gateway logs, metrics, sessions, and config stores.
Filter risky file, database, browser, shell, or production tools before exposing them to a client.
Host custom in-process tools in a Go application that embeds Bifrost.
Safety and Privacy
Bifrost is gateway infrastructure. A single MCP endpoint can expose many
downstream tools, so configure virtual keys, tool allowlists, auth modes,
network access, TLS, and host-side approval rules before sharing it with agent
clients. Be especially careful with downstream servers that can read or write
files, run shell commands, change infrastructure, query production databases, or
modify third-party accounts.
The docs emphasize that default LLM tool calls are not executed automatically
without an explicit tool execution call, but agent mode can be configured for
automatic execution. In pure MCP gateway mode, the external host decides whether
tool calls need user approval. Review the approval settings in Claude Desktop,
Cursor, Cline, or any custom MCP client that connects to Bifrost.
Bifrost can handle provider credentials, virtual keys, MCP auth headers, OAuth
tokens, per-user credentials, prompts, model responses, tool arguments, tool
results, request logs, traces, metrics, and config-store data. Treat those
stores as sensitive, keep secrets out of committed config, and define log
retention before routing production traffic through the gateway.
Duplicate Check
No maximhq/bifrost entry, Bifrost MCP Gateway entry, or matching source URL
was found in content/mcp or the broader content directories.
Show that Bifrost MCP Gateway is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/mcp/bifrost-mcp-gateway)
How it compares
Bifrost MCP Gateway side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
Open-source AI gateway that can connect to downstream MCP servers and expose their aggregated tools through a single HTTP or SSE MCP endpoint for Claude Desktop, Cursor, and other MCP clients.
Docker's MCP CLI plugin and gateway for running catalog, OCI, registry, or local-file MCP servers in containers and exposing them to Claude, Cursor, VS Code, and other MCP clients through a shared gateway profile.
Dashboard, CLI, and gateway for centrally managing many MCP servers and exposing them as authenticated all-server, group, single-server, or smart routing endpoints.
✓Bifrost can expose all selected downstream MCP tools through one `/mcp` gateway endpoint, so treat the endpoint like an access layer for every connected tool.
The docs state that default LLM tool calls are suggestions until an explicit tool execution API call is made, but agent mode can enable configured automatic execution.
Gateway-mode auto-approval is controlled by the external MCP host, such as Claude Desktop, Cursor, Cline, or a custom client, not by Bifrost's `tools_to_auto_execute` setting.
Stdio connections spawn local commands inside the Bifrost runtime; Docker deployments need images that include the requested executables.
Use virtual keys, per-tool allowlists, auth headers, OAuth, per-user credentials, and network controls to limit which clients can reach high-impact tools.
✓Docker MCP Gateway can start and route multiple MCP servers, so each connected client inherits the permissions of every enabled server and tool.
Container isolation reduces host exposure, but Docker Engine or Docker socket access is still highly privileged and should be limited to trusted users.
The gateway supports tool allowlists, CPU limits, memory limits, network blocking, secret blocking, image signature verification, and interceptors; review defaults before production use.
Catalog, profile, local-file, and registry references can change which servers run behind the gateway, especially when watch mode or shared profiles are enabled.
Tool-call logging is enabled by default in the documented flags, so avoid routing secrets or sensitive payloads unless logging and retention are controlled.
✓MCPHub centralizes many downstream MCP servers, so one hub endpoint can expose broad read, write, file, shell, browser, database, or account capabilities depending on the registered servers.
The Docker command binds the dashboard and gateway to 127.0.0.1 by default; use a reverse proxy with TLS and explicit access controls before exposing MCPHub on a network interface.
MCP endpoints require authentication by default; do not disable bearer authentication outside trusted local testing.
Smart routing can discover and invoke tools by semantic similarity, so keep group visibility and bearer-key scopes narrow.
Hot-swappable configuration can add, remove, or change downstream MCP server access while the hub is running.
OAuth server mode, OAuth client mode, social login, and database mode introduce additional credential and session management responsibilities.
✓Archestra is a platform/control-plane entry, not a single-purpose local MCP helper; admins can expose many MCP servers, agents, tools, and credentials through one gateway.
The upstream quickstart mounts the host Docker socket so the platform can run MCP servers; treat that as highly privileged host access and avoid using it on sensitive machines without isolation.
Self-hosted MCP servers may run as Kubernetes workloads with injected environment variables, secrets, images, network policies, and restart controls.
Tool assignments, gateway visibility, credential resolution, custom headers, and load-tools-on-demand settings should be reviewed per team and environment.
Deterministic tool guardrails can reduce some unsafe tool chains, but they depend on correct policies and do not make untrusted MCP servers safe by default.
Privacy notes
✓Bifrost may process provider prompts, model responses, MCP tool names, tool arguments, tool results, headers, virtual keys, OAuth tokens, per-user credentials, logs, traces, metrics, and downstream server metadata.
Per-user auth stores credentials against a signed-in user, virtual key, or session identity; review credential lifecycle, revocation, and orphaned-session behavior.
Logs, config stores, provider settings, MCP sessions, and gateway analytics can contain sensitive operational or user data.
Keep real provider keys, virtual keys, OAuth secrets, MCP endpoint URLs, and upstream service credentials in environment variables or secret stores, not committed config.
✓Docker MCP Gateway may process MCP server definitions, catalog entries, profile exports, local server files, secrets, OAuth tokens, tool names, tool arguments, tool outputs, logs, container metadata, and Docker Engine metadata.
Secrets may come from Docker Desktop secrets or `.env` fallback files; keep those stores out of version control and restrict filesystem permissions.
Tool outputs can include local files, API responses, credentials, account data, or infrastructure details depending on the enabled downstream MCP servers.
Exported profiles and catalogs can reveal internal server names, image references, allowed tools, configuration values, and service endpoints.
✓MCPHub may handle prompts, tool names, tool arguments, tool results, server configs, resource data, bearer keys, OAuth tokens, login sessions, user identities, logs, and CLI command history.
Mounted config files, data directories, database rows, vector indexes, generated passwords, and dashboard screenshots can reveal sensitive server names, environment variables, credentials, and tool schemas.
Downstream MCP servers may forward private workspace, browser, database, cloud, ticketing, or account data through MCPHub to connected clients and model providers.
Do not commit real `mcp_settings.json` files, bearer keys, OAuth secrets, social-login credentials, database URLs, generated admin passwords, or exported hub data.
✓MCP server definitions, tool schemas, gateway tokens, upstream credentials, OAuth tokens, API keys, custom headers, logs, traces, and tool results may be stored or processed by the platform.
Built-in observability, LLM proxy, chat, agents, and policy features can reveal prompts, tool arguments, tool outputs, token usage, user identities, team membership, and trace metadata.
Registry entries and installations can use personal, team-scoped, or shared credentials; choose the narrowest scope that matches the use case.
When external MCP clients call an Archestra gateway, downstream tool results can still be sent by the MCP client to the configured model provider.
Prerequisites
Node.js with `npx`, Docker, or another supported Bifrost Gateway deployment path.
Bifrost Gateway version `v1.4.0-prerelease1` or newer for MCP gateway mode.
Downstream MCP server commands or HTTP/SSE endpoint URLs prepared before registering clients.
Provider API keys, virtual keys, gateway auth settings, and governance policies reviewed before sharing the endpoint.
Docker Desktop `4.59+` with the MCP Toolkit feature enabled, or the Docker MCP CLI plugin built and installed independently.
Docker Engine access for running containerized MCP servers and the gateway.
MCP server sources prepared from Docker MCP Catalog entries, OCI images, MCP Registry entries, or local YAML/JSON server files.
Profiles feature enabled when using `docker mcp profile` and profile-based gateway runs outside Docker Desktop.
Docker available for the documented container deployment.
A reviewed `mcp_settings.json` file for the MCP servers the hub should launch or proxy.
A durable mounted data directory so credentials, generated passwords, sessions, and state survive restarts.
OpenSSL or another secure random generator available to create a unique administrator password.
Docker for local evaluation, or Kubernetes and Helm/Terraform-style deployment planning for production use.
Organization policy for which MCP servers, credentials, teams, environments, and external network destinations may be exposed.
LLM provider keys or local model configuration if using Archestra's built-in chat, agents, or LLM proxy features.
Admin review of the quickstart container command before mounting the Docker socket.