Six open-source MCP gateways and MCP Hangar, a policy enforcement plane for MCP that runs on a laptop, a VM or Kubernetes, compared on fifteen rows from caller authentication to tool contract integrity. Every cell links to code or docs at a pinned commit, verified on.
How we compared
Each repository was cloned at its default branch and every cell was read at that commit. The commit is listed under the table.
Code first: a search, then the whole file, then the path from a request handler or config to the mechanism. Docs are secondary evidence, and required for any feature a vendor sells separately.
A mechanism without a path to it from a request is partial, and the note says what is missing. A row that names two things is yes only when both are there.
no means the project says so, and links where.no evidence at <sha> means the code at that commit was searched and nothing was found. The two are not the same claim and are never shown as one.
MCP Hangar was verified the same way, from its own code at a release tag, not from its README or this site.
Multi-provider routing with fallbacks; per-virtual-key budgets, token and request rate limits
partial
OpenAI-compatible proxy to OpenAI/Azure/Anthropic/Bedrock/watsonx/Ollama; per-token request limits; no budgets
yes
LLM proxy on Bifrost with provider routing, fallbacks, per-profile budgets on spend, tokens or requests per user
no evidence at 7e0f342
No LLM provider routing or budgets; OpenAI API is used for find-tools embeddings
no evidence at cf9f5e9
No LLM traffic proxy; preview agent runner calls one Azure OpenAI/Foundry deployment as a client
no
VISION non-goal: not replacing Envoy AI Gateway or its AI gateway capabilities; rate limits apply to MCP traffic
no, by design
README non-goal: no model routing, provider failover or token budgets; none found in code at 0c70812
Desktop and device MCP inventory
enterprise
Bifrost Edge endpoint agent inventories MCP servers in desktop AI app configs; needs Enterprise with Edge entitlement
no evidence at 1f8b9bf
No scanning of desktop MCP client configs or endpoint agent found
yes
Obot Sentry agent (separate MIT repo) uploads scans of MCP servers, skills, clients; inventory views in server
partial
CLI reads local MCP client configs (Claude, Cursor, Codex, others) on one machine; no fleet inventory or endpoint agent
no evidence at cf9f5e9
No desktop/device MCP config discovery or endpoint agent found
no evidence at 98a4ccb
No desktop or endpoint MCP config discovery found
partial
mcp-hangar init reads Claude Desktop, Claude Code and Cursor configs on one machine and imports them; no fleet agent
Sandboxed server runtime and catalog UI
partial
Catalog: MCP library with browse/install UI; runtime: stdio servers as host subprocesses, no sandbox
partial
Catalog: entries registered from the admin UI and API; no container or sandbox runtime found
yes
Runtime: Docker containers or K8s pods; catalog with browse UI and API
partial
Runtime: each server in its own Docker container; catalog CLI in OSS, browse UI in Docker Desktop
partial
Runtime: images deployed as K8s StatefulSets; portal registers images by name, no catalog
no evidence at 98a4ccb
Does not launch MCP servers; discover_tools meta-tool lists registered tools, no install catalog
partial
Runtime: Docker/Podman (read-only, cap-drop) and operator Deployments; catalog: 4-entry CLI list, no UI
Where Hangar is the wrong choice
Hangar decides what happens to a tool call. It does not route model traffic, it reads the MCP client configs on one machine but keeps no inventory across a fleet of them, and its server list is a short CLI list, not a catalog to browse. If one of those is the job, or the platform around it is already chosen, these fit better:
LLM routing, provider failover and model budgets: Bifrost, which is an LLM gateway with MCP built in.
An inventory of the MCP servers on every developer's machine: Obot, whose Sentry agent reports them to the server.
Isolating MCP servers on a developer machine: Docker MCP Gateway, which runs each server in its own container.
Federating REST and gRPC services as MCP tools: ContextForge.
An Azure and Entra ID estate: Microsoft MCP Gateway.
A cluster already run on Envoy, Gateway API or Istio: Kuadrant MCP Gateway, which plugs into the policy you have.
The empty row
Tool contract integrity is a digest over a tool's name, description and schemas, recorded when the tool is approved and checked when it is called. A pinned tool whose definition changes after you said yes to it is refused or withheld, not served. At the commits above, the code of the other 6 projects shows no evidence of one. How digest pinning works and the MCP CVE ledger show why it matters.