5 Best MCP Gateways in 2026: Bifrost, IBM ContextForge, Obot, Docker and Microsoft Compared

Your first agent had three MCP servers and one developer. Six months later it has forty servers, three teams, a shared GitHub token in a config file nobody owns, and a security review asking a simple question nobody can answer: which agent called which tool, with whose credentials, and what came back?

That question is what an MCP gateway exists to answer. Picking one in 2026 comes down to three things: who is allowed to call which tools, whose credentials reach the upstream server, and whether you can prove what happened afterwards.

TL;DR

• Bifrost: best for enterprises that want the MCP gateway and the LLM gateway in one self-hosted layer, with per-key tool scoping, OAuth in both directions and Code Mode for large tool catalogs.
• IBM ContextForge: best if you need to federate MCP, A2A, REST and gRPC services behind one endpoint and you are comfortable running Python.
• Obot: best for platform teams that want a curated, self-hosted catalog of approved MCP servers with group-based access.
• Docker MCP Gateway: best for running local and third-party MCP servers in isolated containers on a developer machine.
• Microsoft MCP Gateway: best for Azure shops that want MCP servers deployed and routed on Kubernetes behind Entra ID.

What an MCP gateway actually does

The Model Context Protocol gives agents a standard way to discover and call tools. It does not, on its own, decide who should see which tool, where credentials live, or what gets logged. Without a gateway, every agent connects to every server directly, and each of those connections carries its own config, its own token and its own blind spot.

An MCP gateway puts one endpoint in front of all of them. Clients connect once. The gateway authenticates the caller, filters the tool list down to what that caller is allowed to use, attaches the right upstream credential, and records every call.

If that sounds like an API gateway, the difference is what it understands. An API gateway sees paths and headers. An MCP gateway sees tool names, arguments and results, which is exactly where agent risk lives. Maxim has a good breakdown of the differences between an MCP gateway, an MCP proxy and an MCP server if you are still deciding which layer you need.

The five gaps a gateway has to close

• Authenticate the caller: know which agent, and which user behind it, is making every request.
• Filter tools per key: each agent sees only the tools it is allowed to call, not every tool on every server.
• Attach per-user credentials: the upstream server gets that user’s own token, not a shared one.
• Inspect arguments and results: check what goes into a tool call and what comes back out.
• Log every call: keep one audit trail of who called which tool, with what, and what happened.

Each of these shows up in the MCP security best practices and in OWASP’s excessive agency entry. A gateway worth deploying closes all five.

How I evaluated them

I looked at five things that decide whether an MCP gateway survives a security review and a real rollout:

• Caller authentication: how the gateway knows who is calling.
• Tool scoping: whether different callers see different tools.
• Upstream credentials: whether each user’s own identity reaches the tool, or one shared token does.
• Payload inspection and logging: whether you can block bad arguments and replay what happened.
• Deployment: where it runs, and what it takes to operate.

All five are open source, so everything below comes from each project’s current docs and repository, checked in October 2026.

Comparison at a glance

1. Bifrost

Bifrost is the open-source AI gateway from Maxim AI, written in Go and licensed Apache 2.0. It is an LLM gateway and an MCP gateway in the same binary: it connects to your MCP servers as a client, then exposes every tool it is allowed to share through a single /mcp endpoint that Claude Desktop, Cursor or any MCP client can point at.

The part that matters for governance is that the caller identity is a virtual key. Send the key, and tools/list only returns what that key may use:

curl -X POST http://localhost:8080/mcp \
  -H "x-bf-vk: vk_support_agent" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The allow-list is a few lines of config per key, down to individual tools:

{
  "name": "support-agent",
  "mcp_configs": [
    { "mcp_client_name": "filesystem", "tools_to_execute": ["read_file"] },
    { "mcp_client_name": "web_search", "tools_to_execute": ["*"] }
  ]
}

What stands out

• Auth in both directions. Callers authenticate with virtual keys or OAuth 2.1, and upstream servers can use static headers, OAuth, per-user OAuth or per-user headers, so the user’s own identity reaches the tool instead of a shared service token.
• Scoping at three levels. Tool filtering works per server, per request and per virtual key, and Virtual MCPs bundle a curated tool set behind its own endpoint.
• Code Mode for big catalogs. Instead of loading every tool schema into the prompt, Code Mode gives the model four meta-tools and lets it write one script that runs in a sandboxed Starlark interpreter. In Maxim’s published benchmark, input tokens fell by 58% at 96 tools and by 92.8% at 508 tools, with the pass rate held at 100%.
• One layer for models and tools. The same gateway handles routing, failover, budgets and observability for LLM calls, so model spend and tool calls land in the same logs under the same key.

Best for: Bifrost is built for enterprises running mission-critical AI agents that need best-in-class performance, security and governance across every model and tool call. It unifies the LLM gateway, MCP gateway and agents gateway into a single platform, and supports air-gapped, VPC and on-prem deployments for regulated industries, with full control over data, access and execution.

Watch out for

• The paid line. Guardrails on tool arguments and results, signed audit logs, RBAC, token exchange and in-VPC deployments are Enterprise features.
• Vendor numbers. The Code Mode figures are Maxim’s own. The mechanism is sound, but measure it on your own tool catalog.

Pricing: open source is free. Enterprise is custom, with a 14-day trial.

2. IBM ContextForge

ContextForge is IBM’s open-source registry and proxy, licensed Apache 2.0 and written mostly in Python. Its pitch is breadth: it federates MCP servers, A2A agents and plain REST or gRPC services behind one endpoint, and can wrap a non-MCP API as a virtual MCP server.

Getting a local instance up is one command, once two secrets are set:

python3 -m mcpgateway.scripts.init_secrets
uvx --from mcp-contextforge-gateway mcpgateway --host 0.0.0.0 --port 4444

What stands out

• Protocol federation. gRPC services can be translated to MCP through server reflection, which saves writing wrappers for internal APIs.
• Virtual servers that bundle tools from several backends, with RBAC on top.
• OpenTelemetry tracing out of the box, with Phoenix, Jaeger and Zipkin as backends.
• A plugin system with dozens of plugins for transports, integrations and guardrail-style checks.

Best for: teams that need to expose existing REST and gRPC services to agents alongside MCP, and want one registry for all of it.

Watch out for

• A Python gateway in the hot path. Fine for most tool traffic, but plan capacity if agents fan out heavily.
• Pre-1.0 maturity. The current images are 1.0 release candidates, so expect configuration to keep moving.

Pricing: free and open source.

3. Obot

Obot is an MIT-licensed platform for running, distributing and governing MCP servers inside an organization. Where the others start from routing, Obot starts from the catalog: which MCP servers are approved, who can use them, and where they run.

What stands out

• Hosting, not just proxying. Obot can run npx, uvx and containerized MCP servers as Docker containers or Kubernetes workloads, and proxy servers that live elsewhere.
• Access by user or identity-provider group, with MCP OAuth and credential management handled by the platform.
• Filters on requests and responses through MCP or webhook filters, so a call can be inspected, changed or rejected before it lands.
• Audit logs you can slice by user, server and tool, plus composite servers that expose selected tools from several backends.

Best for: platform teams that want employees to pick MCP servers from an approved internal catalog instead of installing whatever they find.

Watch out for

• The Docker quickstart is for evaluation. It mounts the Docker socket; production and multi-tenant installs are meant for Kubernetes.
• A smaller community. Around a thousand GitHub stars, so expect fewer third-party guides.

Pricing: free and open source.

4. Docker MCP Gateway

Docker MCP Gateway is the engine behind the docker mcp CLI plugin and the MCP Toolkit in Docker Desktop. It is MIT licensed, and its strength is isolation: every MCP server runs in its own container with limited CPU, memory and network access.

The security switches are flags on one command:

docker mcp gateway run --profile dev-tools \
  --verify-signatures --block-network \
  --cpus 1 --memory 2Gb

--block-secrets and --log-calls are on by default, so secrets are kept out of tool traffic and every call is logged. --interceptor lets you run your own script before or after a tool executes.

What stands out

• Container isolation per server, which is the right default for third-party MCP servers you have not audited.
• Signed images through --verify-signatures, so you only run what the publisher actually shipped.
• Profiles that decide which servers and tools a client gets, and a one-line docker mcp client connect for Claude Code and other clients.

Best for: developers and small teams running local or third-party MCP servers who want isolation with almost no setup.

Watch out for

• Single-user by design. There is no multi-tenant caller authentication; over network transports, its only protection is a local auth token that blocks DNS-rebinding attacks (a malicious web page tricking the browser into calling a local service).
• Not a central control plane. It governs one machine well, not an organization.

Pricing: free and open source; Docker Desktop terms apply if you use the Toolkit UI.

5. Microsoft MCP Gateway

Microsoft MCP Gateway is a reverse proxy and management layer for MCP servers on Kubernetes, built on .NET 8 and MIT licensed. You register each MCP server as an adapter, and the gateway deploys it, routes requests to it and manages its lifecycle.

What stands out

• Entra ID authentication with role-based access: read access through configured roles, write access limited to the creator or an mcp.admin.
• A control plane API to deploy and register servers (POST /adapters) and a tool router that sends calls to registered tool servers (POST /mcp).
• Azure-ready deployment through Bicep templates that provision AKS, Container Registry and Cosmos DB, plus a small management portal.

Best for: Azure-first organizations that want MCP servers deployed, scaled and authorized the same way as the rest of their Kubernetes workloads.

Watch out for

• Latest-spec clients only. The current version requires clients on the 2026-07-28 MCP spec and drops legacy initialization.
• Thin on governance. No per-user upstream credentials or payload inspection are documented, so pair it with something that covers those.

Pricing: free and open source; you pay for the Azure resources it runs on.

How to choose

Start with the question that removes the most options: is this for one developer’s machine, or for the whole organization?

• One machine. Docker MCP Gateway gives you isolation and signed images with almost no work.
• The organization. You need central caller authentication, per-user credentials and an audit trail. If you also route LLM traffic and want models and tools governed under the same keys, Bifrost covers both. If your priority is a curated internal catalog, Obot. If you need REST and gRPC alongside MCP, ContextForge. If everything runs on AKS behind Entra ID, Microsoft’s gateway.

Then pressure-test the pick on the two things that bite later: what happens to tokens when your tool count triples, and whether you can answer “who called what” from the logs alone.

One more gap worth naming: all five govern servers you route through them. Desktop agents can still talk to MCP servers installed locally on a laptop. Bifrost Edge, currently in alpha, extends the same policies to employee devices by inventorying local MCP servers and enforcing allow or deny on the machine itself.

FAQ

What is an MCP gateway?

An MCP gateway is a single endpoint that sits between AI clients and the MCP servers they use. It authenticates the caller, filters which tools that caller can see, attaches the right credentials for each upstream server, and logs every tool call. Bifrost’s MCP gateway guide shows the pattern end to end, from connecting servers to scoping tools per virtual key.

Which MCP gateway is best in 2026?

It depends on scope. For an organization that wants tool governance, per-user credentials and LLM routing in one self-hosted layer, Bifrost is the most complete of the five. For isolating local servers on a developer machine, Docker MCP Gateway is the simplest. ContextForge fits protocol federation, Obot fits catalog-driven governance, and Microsoft’s gateway fits Azure Kubernetes estates.

Do I need an MCP gateway if I only run a few MCP servers?

Once more than one person or agent uses them, usually yes. Even three servers mean three sets of credentials and no shared log. A gateway gives you one place to revoke access, one place to see what was called, and room to add servers later without touching every client config.

How does an MCP gateway handle OAuth?

Two separate flows matter. Inbound, the gateway authenticates the agent or user calling it. Outbound, it authenticates to each upstream MCP server, ideally with that user’s own token rather than a shared one. Bifrost supports both directions, including per-user OAuth to upstream servers; Obot and ContextForge also handle user-scoped OAuth.

What is MCP Code Mode, and why does it cut tokens?

Normally every tool’s schema is loaded into the model’s context on every request, so cost grows with the size of your catalog. Code Mode exposes tools as small stub files the model reads on demand, then runs one script that calls them in a sandbox. The model pays only for what it reads. How Code Mode works in Bifrost walks through the mechanism.

Is an MCP gateway the same as an AI gateway?

No, but they increasingly ship together. An AI gateway governs model calls: providers, keys, budgets, failover. An MCP gateway governs tool calls: which tools, whose credentials, what arguments. Running both in one layer means a single key carries both the model budget and the tool permissions, which is how Bifrost is designed.

Final Thoughts

There is no single best MCP gateway. There is a best one for how far your agents reach and how much you need to prove afterwards.

For one machine, Docker’s gateway is the obvious start. For an organization, the question is whether tool governance lives next to your model traffic or in a separate system. ContextForge, Obot and Microsoft’s gateway each solve one slice well. Bifrost is the one that puts scoped tools, per-user credentials, Code Mode and LLM routing behind the same key, and Bifrost Edge carries those policies out to the laptop.

Whichever you pick, test it the way an attacker would: give an agent a key, ask it for a tool it should not have, and check that the logs tell you exactly what happened.

Teams evaluating MCP gateways can request a Bifrost demo or review the open-source repo.

This post was made in collaboration with the Bifrost team.

Resources & References

• Bifrost on GitHub (open source)
• Bifrost MCP gateway documentation
• IBM ContextForge on GitHub
• Obot on GitHub
• docker mcp gateway run reference
• Microsoft MCP Gateway on GitHub
• MCP security best practices

Stay in Touch

Short takes and discussions on X

→ https://x.com/sebuzdugan

Practical AI / ML videos on YouTube

→ https://www.youtube.com/@sebuzdugan/

Partnerships & collabs

→ [e-mail]

---

Originally published on Medium.