# ToolMesh vs Obot, Docker MCP Gateway, MCPX & IBM ContextForge > An honest 2026 comparison of self-hostable open-source MCP gateways / control planes: ToolMesh, IBM ContextForge, Obot, Docker MCP Gateway, and lunar.dev MCPX — license, authorization, credential isolation, output gating/DLP, audit, REST-to-MCP, and token efficiency. Canonical: https://www.toolmesh.io/en/mcp-gateway-comparison/ A practical, sourced comparison of self-hostable open-source **MCP gateways** (also called MCP control planes): **ToolMesh**, **IBM ContextForge**, **Obot**, **Docker MCP Gateway**, and **lunar.dev MCPX**. We maintain ToolMesh, so treat this as a vendor comparison — but every claim about another project links to that project's own documentation, and we call out where the others are genuinely stronger or more mature. If you spot something inaccurate, [open an issue](https://github.com/DunkelCloud/ToolMesh/issues). This is **not a full market survey** — it focuses on five self-hostable, open-source / open-core control planes. A short [list of other relevant gateways](#other-relevant-gateways) (Microsoft, ToolHive, Envoy, Kong, Pomerium, and more) is at the end. They differ most in **how much governance lives in the open-source core**, and in **how you add tools**: ToolMesh turns a whole REST API into MCP tools from one declarative DADL file (LLM-generatable from OpenAPI). IBM ContextForge can expose REST endpoints as tools too, but each is registered by hand as JSON with no OpenAPI import — so for a real API it is more of a theoretical path than a practical one. The others run or proxy MCP servers you already have. :::note[New to REST APIs? What is an "endpoint"?] A REST API exposes each feature as a separate **endpoint** — "list issues", "create a pull request", "get a user", and so on. Real APIs have many of them: GitHub's REST API alone spans several hundred (ToolMesh's GitHub DADL covers around 250 in a single file). That scale is why *how* a gateway turns REST into MCP tools matters — describing a whole API once in a declarative file is a very different amount of work from hand-writing one JSON definition per endpoint. ::: ## TL;DR — one line each - **ToolMesh** — A governance-first control layer (single Go binary). Turns nearly any REST API into governed MCP tools from one declarative YAML file ([DADL](/en/dadl/)), with per-tool/per-user [authorization](/en/authorization/), runtime [credential injection](/en/authentication/), a built-in [Output Gate](/en/output-gate/) (DLP), a SQL audit trail, and a token-saving [Code Mode](/en/code-mode/) — all in the Apache-2.0 core. Best when *declarative REST→MCP*, *token-efficient discovery*, and *a lightweight footprint* matter. - **IBM ContextForge** — The broadest open-source gateway: federates MCP **+ A2A + REST/gRPC** behind one endpoint, with strong RBAC, encrypted per-user credentials, and a 40-plugin guardrail/DLP framework. IBM-backed, just hit 1.0. Best when you need multi-protocol breadth and enterprise-grade maturity — and don't mind a Python stack and per-endpoint tool registration. - **Obot** — A broad MCP platform that also ships an end-user chat client (RAG, tasks). Strong RBAC and credential isolation; some enterprise SSO is paywalled. Best when you want a complete, user-facing product. - **Docker MCP Gateway** — The strongest answer for *running untrusted MCP servers safely*: per-server container isolation, Docker-signed catalog images, a large curated catalog. Best when supply-chain safety and Docker-native DX are the priority. - **lunar.dev MCPX** — Observability- and traffic-control-led (rate limiting, metrics; risk scoring is Enterprise). Best when operational visibility across many agents is the priority. ## Comparison at a glance The table uses **Yes / Partial / No** (clearer than icons for readers and AI assistants); the per-tool sections below explain each "Partial". It scrolls horizontally on narrow screens. | Capability | ToolMesh | ContextForge | Obot | Docker MCP | MCPX | | --- | --- | --- | --- | --- | --- | | Core license | Apache 2.0 | Apache 2.0 | MIT (open-core) | MIT (gateway) | MIT (open-core) | | Self-host runtime | Go binary | Python | Docker / K8s | Needs Docker daemon | Docker / K8s | | REST API → MCP, no server | **Yes — declarative DADL (one file)** | Partial — manual, per endpoint | No | No | No | | Fine-grained per-user authz | Yes — OpenFGA/ReBAC | Yes — RBAC + scoping | Yes — RBAC | Partial (static) | Partial (Enterprise) | | Credentials hidden from LLM | Yes | OAuth: yes; REST tools: no | Yes | Yes (Docker secrets) | Yes (Enterprise) | | Built-in output gate / DLP | Yes — policies + redaction | Yes — PII/secret plugins | Partial (filtering) | Partial (`--block-secrets`) | Partial (not native) | | Audit trail | Yes — SQL-queryable | Partial — logs + OTel | Yes — per-call log | Partial (logs+tracing) | Yes — logs+metrics | | Token efficiency / code mode | Yes — Code Mode | Partial — compression | No | Yes — `code-mode` (exp.) | Yes — dynamic discovery | | Caller / agent trust tiers | Yes — CallerClass | Partial (RBAC) | Partial (RBAC) | No | Partial (per-agent) | | Per-server container isolation | No | No | Partial | **Yes — signed + SBOM** | No | | Multi-protocol (A2A / gRPC) | No (MCP + REST) | **Yes — MCP+A2A+gRPC** | No | No | No | | Curated server catalog | No (DADL registry) | No (own registry) | Yes | Yes — 200+ tools | Yes | | End-user chat client | No | No | **Yes (+ RAG, tasks)** | No | No | Honest read: **no single tool wins every row.** ToolMesh and ContextForge overlap heavily on *governance* (RBAC, credential isolation, output gating) — but on REST→MCP they differ sharply: ToolMesh is declarative and spec-driven (one file, scales to a whole API), while ContextForge's per-endpoint JSON registration does not realistically scale to a large API without writing your own conversion script. ToolMesh also leads on Code Mode and a lightweight single-binary footprint; ContextForge leads on protocol breadth (A2A/gRPC) and maturity; Docker on container isolation; Obot on product breadth; MCPX on observability. ## When to choose which - **Choose ToolMesh** if you want declarative, spec-driven REST→MCP (one DADL file, LLM-generatable from OpenAPI), token-efficient Code Mode, per-tool/per-user authorization, a built-in Output Gate with redaction, and a SQL audit trail — in a single Go binary, fully open core. - **Choose IBM ContextForge** if you need **multi-protocol breadth** (MCP + A2A + REST/gRPC + agent routing) and enterprise maturity (RBAC, SSO, 40-plugin guardrails, IBM backing) — and you're comfortable registering REST tools endpoint-by-endpoint and running a Python service. - **Choose Obot** for a complete, user-facing product (chat client, self-service catalog, RBAC, managed cloud) — accepting that enterprise SSO is a paid add-on. - **Choose Docker MCP Gateway** to run third-party MCP servers safely inside Docker: container isolation, signed images, a large catalog. - **Choose lunar.dev MCPX** for operational visibility and traffic control across many agents — buying Enterprise for the deeper governance. You can also combine them: ToolMesh can sit in front of MCP servers that Docker, Obot, or ContextForge runs, applying its own authorization, credential, gating, and audit layers on top. ## ToolMesh [ToolMesh](https://github.com/DunkelCloud/ToolMesh) is an Apache-2.0, self-hosted control layer (single Go binary). Its distinguishing trait is **[DADL](/en/dadl/)** — a declarative YAML language that turns nearly any REST API into governed MCP tools from **one file**, with no per-API server to write; an LLM can generate the DADL from your OpenAPI spec. Every tool call runs through one pipeline: authenticate → authorize → inject credentials → execute → gate and redact the output → audit. The pipeline is fail-closed for authentication and any enabled gate; OpenFGA authorization is fail-closed in restrict mode (it ships in bypass mode by default). - **Authorization:** per-tool, per-user via OpenFGA (User→Plan→Tool), enforced in restrict mode. - **Credentials:** injected server-side from a pluggable CredentialStore; the model never sees them. - **Output Gate (DLP):** deterministic goja-based JS policies that run before execution (block) and after (redact PII). Layer 1 ships today; further layers in development. - **Audit:** a SQL-queryable trail — every call attributed to a user, plan, and caller. - **Code Mode:** collapses a large tool catalog to roughly 1,000 tokens — in our own catalog about a 142× reduction (≈142,000 → ~1,000), scaling with catalog size — plus progressive, BM25-ranked tool discovery so context cost stays flat. - **Caller trust tiers:** differentiates *which* AI client called (trusted / standard / untrusted) and tiers PII filtering and tool access accordingly. **Where ToolMesh is weaker (be aware):** no per-server container isolation, no signed image catalog, no end-user chat client, and — unlike ContextForge — no A2A/gRPC. It is early-stage (pre-1.0) with small public adoption. Its honest edges are the *declarative one-file* REST→MCP model, Code Mode, and the lightweight single-binary footprint. ## IBM ContextForge [IBM ContextForge](https://github.com/IBM/mcp-context-forge) (MCP Context Forge; Apache-2.0, ~4k stars, Python) is the most direct open-source competitor here — and the broadest. It federates **MCP, A2A, and REST/gRPC** behind one governed endpoint, routes to A2A / OpenAI / Anthropic agents, and reached **1.0 GA in June 2026** with IBM behind it. On governance it is at or near parity with ToolMesh: - **Strong RBAC** — token scoping plus action RBAC (`platform_admin`/`team_admin`/`developer`/`viewer`), per-tool permissions, multi-tenant teams, SSO (Entra/Okta/Keycloak/OIDC). - **Credentials hidden from the LLM — but only for OAuth/MCP upstreams.** Those secrets are encrypted at rest, stored per-gateway and per-user, and applied server-side. A REST endpoint registered via [passthrough](https://ibm.github.io/mcp-context-forge/latest/using/rest-passthrough/) is different: its API key travels as a **caller-supplied tool parameter** mapped to a header (`"apiKey": "secret123"` becomes `X-API-Key: secret123`), so for REST tools the credential is *not* injected server-side or hidden from the model — unlike ToolMesh's DADL, where the server always injects it. - **Guardrails/DLP via a 40-plugin framework** — PII Filter (masks SSN/cards/emails on input *and* output), Secrets Detection, OPA/Cedar policy, LLMGuard — running pre- and post-invocation. A genuine Output-Gate analog. - **Observability** — structured JSON logging + OpenTelemetry tracing; production K8s/Redis federation; airgapped admin UI. **Differences vs ToolMesh — the practical REST→MCP gap:** "ContextForge also does REST→MCP" needs a hard caveat. ToolMesh describes a whole API once in a declarative DADL file (spec as the source of truth, LLM-generatable from OpenAPI). ContextForge registers tools **endpoint-by-endpoint as JSON** via its admin API, and there is **no OpenAPI-spec import** (an [open feature request](https://github.com/IBM/mcp-context-forge/discussions/3466) as of March 2026) — so onboarding a real enterprise API means hand-authoring a tool per endpoint or scripting the OpenAPI→JSON conversion yourself, which is the maintainer's own suggested workaround. For an API with dozens or hundreds of endpoints, that is a meaningful gap, not parity. Worse, that passthrough takes the upstream API key as a **caller-supplied tool parameter** rather than injecting it server-side — so the REST→MCP path also forfeits credential isolation, which is a core reason to put a gateway in front of an API in the first place. ContextForge also has **no Code-Mode / sandboxed-execution analog** and no progressive/semantic tool discovery, its audit is log/OTel-based (no clearly documented queryable audit API), and it runs a heavier Python stack vs ToolMesh's single Go binary. Where ContextForge is clearly stronger: **A2A + gRPC breadth, agent routing, 1.0 maturity, and IBM's backing.** ## Obot [Obot](https://github.com/obot-platform/obot) (by Obot AI, formerly Acorn Labs; founders from Rancher/SUSE; a $35M seed in 2025) is the broadest *product*: beyond the gateway it ships a **registry, MCP-server hosting, and an end-user chat client** with RAG, project memory, and scheduled tasks. - **Strong RBAC** scoped per catalog, server, and tool; policies cover users, groups, and agents. - **Credential isolation is a headline claim** — "Agents don't see raw credentials. Ever." - **Per-call audit** and **composite MCP servers** (combine backends into one virtual server). **Differences vs ToolMesh:** Obot's core is MIT but **open-core** — enterprise SSO (Okta/Entra/Auth0/JumpCloud) is gated to the paid tier. We found **no declarative REST→MCP**, **no turnkey DLP** (request filtering/guardrails, not redaction), and **no Code-Mode-style compression**. Where Obot is stronger: a usable end-user product and, as a dedicated MCP startup, the best-funded of the group. ## Docker MCP Gateway [Docker MCP Gateway](https://github.com/docker/mcp-gateway) (MIT, Go) is the runtime piece of Docker's MCP story (Catalog = signed images on Docker Hub; Toolkit = Docker Desktop UI; Gateway = the OSS proxy). Standout strengths: - **Per-server container isolation** with restricted privileges — the strongest isolation story here. - **Signed catalog images + SBOMs** — most catalog servers are Docker-built with attestations and signed SBOMs, enforced via `--verify-signatures`. - **Server-side secret injection** + a `--block-secrets` interceptor; a `code-mode` feature that Docker labels **experimental** ("not yet reliable for general use"). **Differences vs ToolMesh:** authorization is **static** (no per-user/RBAC/caller identity); **no declarative REST→MCP**; output control is secret **blocking, not redaction**; and the model **depends on a Docker/containerd runtime**. Docker is the better answer for *isolating untrusted servers*. ## lunar.dev MCPX [lunar.dev MCPX](https://github.com/TheLunarCompany/lunar) (MIT, TypeScript) comes from Lunar.dev's API-gateway/observability heritage. (Not the nVIDIA "MCPX" Xbox chip.) - **Observability** — built-in metrics (Prometheus-compatible, from Lunar's gateway lineage) + a low (~4 ms p99) overhead claim. - **Traffic control** — rate limiting, retries, circuit breakers. - **Risk scoring + evaluation sandbox** for untrusted servers — both **Enterprise-tier**. - **Dynamic tool discovery** (`defer_loading`) for token efficiency. **Differences vs ToolMesh:** much of the deeper governance is **Enterprise-tier** (SSO/RBAC, secret isolation, risk scoring); open-source access control is UI/profile-toggle, not a policy engine; **DLP is not a documented MCPX feature** (it lives in Lunar's separate gateway line); audit is logs + metrics, not SQL; and MCPX **aggregates existing MCP servers** — no REST→MCP. Where MCPX is stronger: observability and traffic control. ## Other relevant gateways Not in the head-to-head (different scope, commercial, or smaller), but worth knowing if you're surveying the space: - **[IBM ContextForge](https://github.com/IBM/mcp-context-forge)** — covered above; it *is* in the head-to-head. - **[Microsoft MCP Gateway](https://github.com/microsoft/mcp-gateway)** (MIT) — Kubernetes-native reverse proxy for session-aware routing and lifecycle management of MCP servers you already run. Routes/orchestrates; does not convert REST APIs. - **[Stacklok ToolHive](https://github.com/stacklok/toolhive)** (Apache-2.0 core + commercial Enterprise) — security-focused: each MCP server in its own container with Cedar-policy authz, OIDC, and audit. Runs existing servers; no REST→MCP. - **[Envoy AI Gateway](https://aigateway.envoyproxy.io/)** (Apache-2.0) — Envoy/CNCF-aligned LLM-traffic gateway that *added* MCP aggregation (`MCPRoute`, OAuth, tool filtering). Aggregates; no REST→MCP. - **[agentgateway](https://agentgateway.dev/)** (Apache-2.0, Linux Foundation) — data plane for MCP/A2A with RBAC and tool federation; advertises exposing an OpenAPI API as a tool, but federation is its core. - **[Kong AI Gateway](https://developer.konghq.com/plugins/ai-mcp-proxy/)** (commercial/Enterprise) — its AI MCP Proxy plugin converts Kong-managed REST APIs into MCP tools with Kong's policies applied. The closest enterprise analog to ToolMesh's REST→MCP, but paid and scoped to APIs already onboarded into Kong. - **[Pomerium](https://www.pomerium.com/)** (Apache-2.0 + managed) — identity-aware zero-trust proxy; fronts MCP servers with OAuth and tool-level access policy. Governs access; does not create tools. - **[MCPJungle](https://github.com/mcpjungle/MCPJungle)** (MPL-2.0) — self-hosted registry + gateway for multiple MCP servers. Aggregates; no REST→MCP. - **[Unla](https://github.com/AmoyLab/Unla)** (MIT) — lightweight Go gateway that turns existing APIs and MCP servers into MCP servers via config (REST/gRPC). With Kong, the other genuine REST→MCP claimant — config-file-driven rather than declarative-spec-plus-governance, and a smaller solo-org project.