Top 10 open-source MCP gateways you can self-host in 2026

An open-source MCP gateway is a Model Context Protocol proxy you can run on your own infrastructure that sits between agents and the MCP servers they call, and decides who may see and call which tools, under which credential, with what record. Self-hosting matters for the teams this list is written for: platform and security engineers who cannot send tool traffic, and the credentials behind it, through someone else’s cloud, or who need the gateway inside a VPC, an on-premises cluster or an air-gapped network. We read the documentation and repositories of every serious candidate and ranked the ten we would actually deploy.

The licences are the easy part. All ten projects here are Apache 2.0 or MIT. The hard part is what each free build leaves out: audit logs, single sign-on, guardrails and user caps are where open-core lines get drawn, and those lines move the ranking more than any feature list does. If you are new to the category, the MCP gateway explainer covers how tool filtering, upstream auth and audit work in principle; this piece assumes that and compares products. For a list that also includes managed services, see the companion ranking of the top MCP gateways in 2026.

How we ranked

The overall MCP gateway market includes hosted control planes, API-management add-ons and security products that never ship source code. This list is narrower, so the criteria are too. A gateway qualified only if the MCP gateway itself, not just a client SDK, is published under an OSI-approved licence and can run with no call home to a vendor service. Within that set, we ranked on seven questions, in this order of weight:

1. What the open-source tier actually governs. Per-caller tool filtering, default-deny behaviour, and whether the allow-list is enforced at tools/call as well as tools/list. A gateway that hides tools but executes any call it receives is a convenience, not a control.
2. Authentication in both directions. How MCP clients authenticate to the gateway (OAuth 2.1, JWT, API keys) and how the gateway authenticates to upstream servers (shared tokens, per-user OAuth, token exchange). Per-user upstream credentials score higher than a single shared token.
3. Audit and observability. Tool-call logs, policy-change audit trails, OpenTelemetry and Prometheus export, and whether any of it is paywalled.
4. Guardrails. Inspection or redaction of tool arguments and results, and which providers or plugins do the inspecting.
5. Deployment. Single binary, container, Kubernetes, air-gapped, and the operational weight each implies.
6. Footprint and language. Go and Rust gateways start small and add little latency; Python and TypeScript stacks bring their runtimes and, often, a database and a cache.
7. Community health. Release cadence and last push, checked against the GitHub API on 5 October 2026. A recent release is a stronger signal than popularity.

We also recorded whether each gateway handles LLM traffic as well as MCP. That is a scope distinction rather than a score: a combined gateway lets one identity govern both model calls and tool calls, which we think is the better default for agent platforms, but an MCP-only proxy can be the right answer when an LLM gateway is already in place.

The ten at a glance

Figure 1: Scope matters before features. A combined gateway governs model and tool calls under one key; an MCP-only proxy assumes an LLM gateway exists elsewhere.

1. Bifrost

Bifrost is an open-source AI gateway written in Go by Maxim AI that routes LLM traffic across providers and, in the same process, acts as an MCP client to upstream servers and an MCP server to agents. Its gateway release was v2.2.5 on 2 October 2026.

What the open tier governs. This is where Bifrost pulls ahead. A virtual key with no MCP configuration gets no MCP tools: deny by default, except for servers an administrator marks “Allow by Default”. The allow-list is enforced when the model sees tools and again when a call executes, a caller-supplied x-bf-mcp-include-tools header “can only narrow, never widen” the grant, and an expired key is refused with HTTP 403. Virtual MCPs, curated tool bundles served at /mcp/<slug>, are part of the open-source core; the enterprise tier adds access-profile grants and project scoping on top.

Authentication. Bifrost connects to upstream servers over stdio, HTTP or SSE and supports six upstream auth types: none, static headers, shared OAuth, per-user headers, per-user OAuth with dynamic client registration, and token exchange, the last of which is enterprise. Clients authenticate to the /mcp endpoint with a virtual key header, or, in the oauth gateway mode, through Bifrost’s own authorisation server, which issues a JWT carrying the caller’s identity.

Footprint and deployment. Bifrost’s published benchmark reports 11 µs of gateway overhead per request at 5,000 requests per second on a t3.xlarge. It runs as a binary, a container or a Helm release, and documents an air-gapped mode that reads pricing data from local files and disables the MCP catalogue sync. Code Mode, which replaces large tool catalogues with a few meta-tools, is the token-cost answer for agents with hundreds of tools; the Bifrost MCP gateway page summarises how it combines with filtering.

Limitations. HMAC-signable audit logs, OIDC with Okta or Entra, custom RBAC, guardrails, clustering and log exports are part of Bifrost Enterprise. The open tier already logs MCP calls alongside LLM calls, so teams can start on the open build and add the enterprise licence when a security review calls for those controls.

Best for: in our assessment, the strongest open-source starting point for any team running agents in production, because the same key that pays for a model call is the key that is allowed to call a tool, and the defaults are restrictive rather than permissive.

2. agentgateway

agentgateway is a Rust proxy for agent traffic, hosted by the Linux Foundation, that handles LLM routing, MCP and agent-to-agent (A2A) protocols in one data plane. It shipped v1.6.0 on 2 October 2026.

Strengths. agentgateway keeps its policy engine in the open build. Access control is “fine-grained RBAC with CEL policy engine”, and the MCP documentation uses CEL rules to restrict which tools and resources a caller can reach. Its MCP authentication implements the MCP OAuth flow with resource metadata, discovery and dynamic client registration, and acts as a translator for identity providers that do not fully support the MCP profile, with built-in Keycloak support. Static JWT validation covers service-to-service callers. Content filtering spans regex, OpenAI moderation, AWS Bedrock Guardrails and Google Model Armor, and the project documents MCP-aware external authorisation for filtering and mutating calls. It is also the first project here to document support for, and translation between, MCP specification versions including the stateless 2026-07-28 revision.

Deployment. It runs as a standalone binary configured in YAML, or on Kubernetes through a built-in controller using the Gateway API. Rust keeps the footprint small and the latency predictable, although the project does not publish a benchmark comparable to Bifrost’s.

Limitations. Power comes as configuration. CEL is expressive, but writing and reviewing authorisation rules is a skill your team will need, and policy lives in YAML or Kubernetes resources rather than in a key-centric admin console. The web UI is an explorer for connections rather than a full governance console, and audit means exporting metrics, logs and traces to a stack you run. MCP tool calls are observable; a tamper-evident policy-change trail is something you assemble.

Best for: platform teams that want every control, including guardrails, in Apache 2.0 code they can read, and are comfortable expressing policy as code.

3. IBM ContextForge

ContextForge is IBM’s open-source gateway, registry and proxy for MCP, which also federates A2A agents and wraps REST and gRPC services as virtual MCP servers. It is written in Python on FastAPI, released v1.0.11 on 28 September 2026 after a run of 1.0.x releases through September.

Strengths. Breadth and a plugin model. The tools gateway federates MCP and REST, translates gRPC to MCP, and extracts JSON Schema automatically when it wraps a non-MCP service, which is the fastest route from an internal API catalogue to governed tools. Authentication is JWT-based, with SSO through Google, GitHub or Entra ID via Keycloak, user-scoped tokens that preserve role context across federated calls, and team-based RBAC. The plugin catalogue lists 16 security-focused plugins, among them a PII filter, secrets detection, content moderation, an LLM Guard integration, OPA and Cedar policy plugins, SQL and HTML sanitisers, and a rate limiter. Tracing exports over OTLP to Jaeger, Zipkin, Phoenix or Datadog. Deployment options include PyPI, OCI images, Helm charts with autoscaling and network policies, and guides for EKS, AKS, Cloud Run and IBM Cloud.

Limitations. Python and the production dependency list carry weight: the documentation recommends PostgreSQL rather than SQLite beyond a single node, and Redis for caching, sessions and multi-cluster federation. That is three services to run before the first tool call. The 1.0 line is recent, so upgrade notes deserve close reading. ContextForge does not route LLM traffic as a full provider gateway, so a team still needs an LLM gateway alongside it, and the identity in one will not automatically match the identity in the other.

Best for: enterprises with large internal REST or gRPC estates that want those services exposed as MCP tools without writing new servers, and that prefer policy delivered as plugins.

4. Agent Router (formerly Envoy AI Gateway)

Agent Router is the project previously called Envoy AI Gateway. On 9 September 2026 it left the Envoy sub-project structure and joined the Agentic AI Foundation, taking a new name and GitHub organisation; the code, maintainers, Apache 2.0 licence, CRDs and aigw CLI are unchanged, and old documentation URLs redirect. It released v1.1.0 on 21 August 2026.

Strengths. Agent Router is a control plane on top of Envoy Gateway, so it inherits Envoy’s data plane and its operational track record. MCP is configured through the MCPRoute API, which aggregates several MCP servers into one endpoint and prefixes tools with the backend name (for example github__issue_read). The documentation lists native OAuth 2.1 enforcement and authorisation using JWT scopes, custom claims and CEL expressions that can see the MCP method, backend, tool name and parameters. Tool filtering uses a toolSelector with exact matches or regular expressions. Upstream credentials are injected as API keys or headers, sessions across several backends are encoded into one session ID with SSE reconnection, and every MCP request produces OpenTelemetry traces and Prometheus metrics. The same gateway handles LLM traffic to 15 or more providers with rate limiting and failover.

Limitations. It assumes Kubernetes and Envoy Gateway; the standalone aigw CLI exists for local use, but production means CRDs. Upstream auth is header injection, with no documented per-user OAuth to upstream servers. The MCP page describes alignment with the June 2025 specification, so check release notes before relying on clients that only speak the 2026-07-28 revision. The rename also means a period in which tutorials, Helm repositories and search results use both names.

Best for: Kubernetes platform teams already running Envoy Gateway who want MCP routing and OAuth as more CRDs in the same control plane.

5. Obot

Obot is an MIT-licensed platform, written in Go, that combines an MCP gateway, an MCP and skills registry, hosting for MCP servers on Kubernetes, an LLM gateway and a chat interface. It released v0.26.2 on 2 October 2026.

Strengths. Obot is the most complete answer here to “where do our MCP servers live?”. It hosts servers as Kubernetes workloads, presents a catalogue to users, and controls access by user or identity-provider group. Audit is a first-class feature: Obot records MCP requests and responses, LLM gateway requests with token usage and cost, and tool calls from local AI clients captured by its Obot Sentry component. MCP or webhook filters can inspect, reject or modify requests and responses, which is where a team plugs in its own guardrail service. The role model includes an Auditor role, so only designated users can view sensitive tool-call content.

Limitations. The licence is MIT, but the editions page draws a line that matters for self-hosters. The default edition supports up to 100 users and 100 devices with local, GitHub and Google authentication. Entra, Okta, JumpCloud and Auth0 require the free, registration-based Community edition, which keeps the same cap; unlimited users and devices require Obot Enterprise. For a company of any size, that makes Obot open-core in practice. It is also a whole platform: if all you want is a policy proxy in front of existing servers, it brings more surface area than you need.

Best for: companies that want to host and catalogue MCP servers centrally, with per-group access and full request logging, and that fit within, or will pay beyond, the 100-user line.

6. Docker MCP Gateway

Docker MCP Gateway is the MIT-licensed Go project behind the MCP Toolkit in Docker Desktop. It runs as the docker mcp CLI plugin and starts each MCP server from the catalogue in its own container. It released v0.44.1 on 23 September 2026.

Strengths. Isolation is the point. The security model is the most concrete in this list for the risk of running untrusted server code: containers run with CPU and memory limits and minimal host privileges; --block-secrets, on by default, scans tool arguments and responses for secret-like values before and after execution; signature verification is on by default for images in Docker Hub’s mcp/ namespace; --log-calls, also on by default, records tool names and argument shape without raw values; and --block-network restricts egress when set. HTTP transports require bearer-token authentication unless --allow-unauthenticated is passed. Profiles group servers with per-server tool allow-lists and can be shared through OCI registries, and the gateway handles OAuth flows to remote services.

Limitations. It is built around one operator’s machine or one service account. There is no per-user identity, no team-level RBAC and no per-caller tool policy beyond what each profile enables, and the default egress posture is open. It runs on Docker Engine as well as Desktop, but there is no documented Kubernetes deployment. Air-gapped use means mirroring the catalogue and images into a private registry.

Best for: developers and CI pipelines that run third-party MCP servers and want each one sandboxed, with secrets scanning on by default.

7. Microsoft MCP Gateway

Microsoft MCP Gateway is an MIT-licensed reverse proxy and management layer, written in C# on ASP.NET Core, that routes, authorises and manages the lifecycle of MCP servers in Kubernetes. It was last pushed on 2 October 2026; the repository does not publish tagged releases.

Strengths. It treats MCP servers as Kubernetes workloads: servers and a tool router run as StatefulSets behind headless services, and a control-plane REST API manages adapters at /adapters and tool definitions at /tools. The data plane routes to /adapters/{name}/mcp or to a tool router at /mcp that dispatches each tool call to the right server. Routing is stateless; each request carries its own protocol metadata and is authorised independently, which suits horizontal scaling and lines up with the direction of the 2026-07-28 specification. Authentication uses Entra ID bearer tokens, with an mcp.admin app role for write access and custom roles for read access.

Limitations. It is Entra-first and Kubernetes-only for production; teams on Okta or without AKS-style infrastructure will be fighting the defaults. The documented role model governs who can manage and read adapters; a per-caller tool allow-list comparable to Bifrost’s or agentgateway’s is not documented, nor are guardrails or a policy-change audit trail. Telemetry to Microsoft is on by default and can be disabled. The session-management APIs are marked preview.

Best for: Azure and Entra ID organisations that want MCP servers deployed and routed as first-class Kubernetes services.

8. Higress

Higress is a cloud-native API and AI gateway built on Istio and Envoy and extended with WebAssembly plugins. It originated at Alibaba, is a CNCF sandbox project, is licensed Apache 2.0, and released v2.2.5 on 4 October 2026.

Strengths. Higress approaches MCP from the API side. Its MCP Server plugin has two modes: rest, which turns REST endpoints into MCP tools through request and response templates, and mcp-proxy, which fronts existing MCP servers. Security schemes are defined once and referenced per tool, with separate client-to-gateway and gateway-to-backend authentication (Basic, Bearer or API key), optional credential passthrough, a static allowTools list, and an x-envoy-allow-mcp-tools header that upstream plugins can set to narrow tools dynamically per request. The project describes unified auth, fine-grained rate limiting and audit logs for tool calls, and it covers LLM routing, token rate limits and caching in the same gateway. Its ingress heritage is the reason it tops the star count.

Limitations. Running Higress well means running Envoy, Istio-style configuration and Wasm plugins; it is a lot of gateway for a team that only wants MCP governance. Client authentication is credential-based, with no documented MCP OAuth 2.1 flow for clients such as Claude Code. Tool filtering is static per server unless you write a plugin that sets the header. Some documentation and community discussion is Chinese-first.

Best for: organisations already using Higress, or needing a high-throughput ingress, that want to publish existing REST APIs as MCP tools with per-tool auth.

9. Unla

Unla is a lightweight MCP gateway, written in Go with a web management UI, that converts REST, gRPC and WebSocket services into MCP endpoints and proxies existing MCP servers. It is MIT-licensed, released v0.10.0 on 4 August 2026.

Strengths. Unla is small and does one job. Configuration hot-reloads through OS signals, HTTP or Redis pub/sub, so new tools appear without a restart. It supports multiple replicas, groups and aggregates servers per tenant, and persists configuration to disk, SQLite, PostgreSQL or MySQL, so it can start with a file and grow into a database. It runs on bare metal, VMs, ECS or Kubernetes with a Helm chart. OAuth-based pre-authentication for MCP servers is supported.

Limitations. Governance is thin compared with the top half of this list. There is no documented per-caller tool allow-list, no guardrail framework, no audit trail beyond logs, and no LLM routing. The release cadence has slowed: v0.9.2 shipped in January 2026 and v0.10.0 in August. The contributor base is small, so plan to read the code when something is unclear.

Best for: small teams that want a single, easily understood front door for a handful of internal APIs and MCP servers, and will add policy elsewhere.

10. MetaMCP

MetaMCP is an MIT-licensed aggregator, orchestrator and middleware layer that groups MCP servers into namespaces and publishes each namespace as an endpoint. It is a TypeScript application (Next.js front end, Express and tRPC back end) shipped as a single Docker Compose stack.

Strengths. The namespace model is easy to explain: put the servers a team needs in a namespace, attach it to an endpoint, and hand the team that endpoint. Tool names, titles and descriptions can be overridden per namespace, and middleware intercepts and transforms requests and responses at namespace level; the built-in example filters inactive tools. Authentication covers API keys, OAuth per the 2025-06-18 MCP specification, and OIDC SSO with providers including Auth0, Keycloak, Azure AD, Google and Okta. A built-in inspector helps debug endpoints.

Limitations. Maintenance is the concern. The latest tagged release is v2.4.22 from 19 December 2025 and the last push to the default branch was 22 June 2026; the maintainer has noted delays. The project recommends 2 to 4 GB of memory for an online deployment, which is heavy for a proxy. Logging is configurable by level but there is no audit trail, guardrail framework or LLM routing. We include it because it is still widely deployed and the namespace pattern is useful, but we would not start a new production deployment on it without a plan to fork.

Best for: small teams or homelabs that want to bundle MCP servers into shareable endpoints with SSO, and can live with slower upstream maintenance.

What did not make the list, and why

Two well-known gateways were on our initial list and dropped out on the evidence.

Kong Gateway OSS. Kong’s open-source gateway is widely deployed, but its AI MCP Proxy plugin is marked “only available as part of our AI Gateway Enterprise offering” and requires Kong Gateway 3.12 or later. Without it, Kong OSS can proxy MCP over HTTP like any other traffic, but it cannot filter tools or understand MCP methods, so it does not qualify as a self-hostable MCP gateway in the sense used here.

kgateway. The kgateway documentation now states that “AI, MCP, and LLM connectivity are documented on Agentgateway”; kgateway itself remains an Envoy-based gateway for ingress, egress and mesh traffic. Teams on kgateway should evaluate agentgateway, ranked second above.

What actually differs between them

Read side by side, the ten differ on five axes. Feature lists that say “OAuth” or “RBAC” hide most of it.

Default-deny and enforcement point

The most important security property is what a new caller can do before anyone configures it. Bifrost denies all MCP tools to a key with no MCP configuration. agentgateway and Agent Router deny or allow according to the CEL rules you write, so the default is whatever your policy says. Higress allows all tools unless allowTools is set. MetaMCP and Unla expose what is in the namespace or group. The second half of the property is whether the list is checked when a tool is called, not only when tools are listed; Bifrost documents both checks explicitly, and CEL-based gateways evaluate the call itself.

Who authenticates to whom

Client-to-gateway authentication has converged on OAuth for interactive clients and JWTs or API keys for services. The bigger gap is upstream. Bifrost’s per-user OAuth and per-user headers, and ContextForge’s per-user delegated tokens, let an agent act with the end user’s own permissions on GitHub or Notion. Agent Router, Higress and Docker inject a shared credential per server. Shared credentials are simpler, but they give every caller the union of the token’s access.

Where the open-core line sits

Fully open does not mean cheaper to run. agentgateway and ContextForge give you guardrail hooks, but you still operate the guardrail services and the observability stack, and you write the policies. Bifrost’s enterprise tier sells those as product features; on the AI governance page the vendor lists the identity providers, budget hierarchy and audit fields that tier adds, and the AI guardrails page lists the PII, secrets and prompt-injection checks and the external providers it integrates. Which is cheaper depends on whether your team would rather pay a licence or own the integration.

Guardrails on tool calls, not just prompts

Prompt guardrails on LLM traffic are common. Guardrails on MCP arguments and results are not. Bifrost Enterprise applies rules at both boundaries of a tool call, with CEL expressions such as mcp_client == "github" && mcp_tool == "create_issue" to target one tool, and can redact before execution or withhold a result from the model. ContextForge’s PII and secrets plugins run as pre and post hooks on tool traffic. Docker’s --block-secrets scans both directions by default. The others either have no MCP-specific inspection or leave it to an external filter you write.

Observability and the specification moving underneath

Every gateway here logs something; few treat tool calls as first-class telemetry. Bifrost writes MCP logs alongside LLM logs and exports to Prometheus and OpenTelemetry, which the vendor’s AI observability page describes as captured once at the gateway rather than instrumented in each application. Agent Router emits traces and metrics for every MCP request. Meanwhile the 2026-07-28 MCP specification removes sessions, requires Mcp-Method and Mcp-Name headers on Streamable HTTP, deprecates dynamic client registration in favour of Client ID Metadata Documents, and adds cache hints to list responses. Gateways that route on headers and hold no session state will find the transition easiest; check each project’s support before upgrading clients.

Figure 2: Start from the constraint you cannot change. Most teams can eliminate seven of the ten in one question.

Recommendations by constraint

You want one gateway for model calls and tool calls. Start with Bifrost. Virtual keys carry budgets, model access and tool allow-lists together, and the open tier’s default-deny posture is the safest starting point. If your security team requires every policy feature, including guardrails, to be open source, choose agentgateway and budget engineering time for CEL. The broader open-source AI gateways ranking compares the LLM side of these products in more depth.

You must run air-gapped or in a regulated network. Bifrost documents an air-gapped mode explicitly; agentgateway and Unla run as self-contained processes configured from local files, which makes offline operation straightforward to test. Avoid designs that pull catalogues or images from public registries at runtime unless you mirror them.

Your tools are internal APIs, not MCP servers. ContextForge if you want plugins and federation; Higress if you already run it as ingress; Unla if you want something small.

You run third-party servers on developer machines or in CI. Docker MCP Gateway, for container isolation and secrets blocking by default. Pair it with a central gateway for anything shared.

You are on Kubernetes and Entra ID or Envoy. Microsoft MCP Gateway for Entra-native estates; Agent Router if Envoy Gateway is already your ingress.

You need a catalogue and hosted servers for the whole company. Obot, after checking the 100-user line against your headcount.

You have MCP servers on laptops that no gateway sees. None of the ten solves this alone, because a gateway only governs traffic configured to reach it. Bifrost applies governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends the same controls to AI traffic on employee machines, including discovery and allow or deny decisions for locally configured MCP servers. The wider problem is covered in our piece on shadow AI governance.

Choosing

The licences in this list are all permissive, so do not choose on licence. Choose on three things: what a new caller can do before anyone configures it, whose credentials the gateway uses upstream, and which features you would have to buy or build to pass your own security review. Run that test against your top two candidates with your real servers and your real identity provider for a week; the differences that matter show up in the first afternoon of writing policy.

On that test, Bifrost is our first choice for most teams running agents in production, with agentgateway the strongest option when every control must be open source. Teams evaluating either can request a Bifrost demo or start from the Bifrost source on GitHub, and should read the agentgateway policy docs alongside.

Feature claims are drawn from public documentation and vendor announcements as of October 2026; check current docs before deciding.