Bifrost

Model Context Protocol · access layer

One secure endpoint for every MCP server your team trusts.

Bifrost sits between your AI tooling and a fleet of MCP servers — a single base URL to mount, keys you can scope and rotate, and a live audit log of every invocation.

Docker install · five-minute setup · self-host or cloud

gateway.yamllive · 3 servers
gateway:
  port: 8787
  baseUrl: https://mcp.example.com

servers:
  github:
    url: http://10.0.4.21:3001
  postgres:
    url: http://10.0.4.22:3002

keys:
  rotate: 30d · scopes: tools, prompts
01:48:22GET /mcp · github.get_pull200
01:47:03GET /mcp · postgres.query200
client.jsonclient config
{
  "mcpServers": {
    "bifrost": {
      "url": "https://mcp.example.com",
      "headers": { "Authorization": "Bearer sk_live_…" }
    }
  }
}
  1. 01

    Point one client at Bifrost

    Add a single entry to your client config pointing at your gateway base URL.

  2. 02

    Attach the servers you need

    Register any MCP server — internal or external — and let Bifrost resolve and proxy by tool name.

  3. 03

    Issue keys, then watch it work

    Scope keys per tool or team, rotate them on a schedule, and audit every call from one dashboard.

What's different

The access layer your fleet has been missing.

Mount once, route by tool

Point your client at one base URL. Bifrost resolves each tool call to the right server and proxies it — no per-server credentials tangled across your config.

Keys you can scope and rotate

Issue API keys per tool, per team, or per project. Revoke one without rebuilding the fleet — and know exactly who called what, and when.

Observability built in

Every invocation lands in a searchable trace — latency, payload size, status. You see the whole fleet's activity in one pane, without bolting on a stack.

Stop duplicating keys. Mount one gateway.

Self-host it or let us run it — the config is the same either way.

Read the docs

Replace with your project URL · license placeholder