ToolMesh vs Obot, Docker MCP Gateway, MCPX & IBM ContextForge

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.

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 (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.

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), with per-tool/per-user authorization, runtime credential injection, a built-in Output Gate (DLP), a SQL audit trail, and a token-saving 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 is an Apache-2.0, self-hosted control layer (single Go binary). Its distinguishing trait is 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 (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 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 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 (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 (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 (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 — covered above; it is in the head-to-head.
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 (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 (Apache-2.0) — Envoy/CNCF-aligned LLM-traffic gateway that added MCP aggregation (MCPRoute, OAuth, tool filtering). Aggregates; no REST→MCP.
agentgateway (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 (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 (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 (MPL-2.0) — self-hosted registry + gateway for multiple MCP servers. Aggregates; no REST→MCP.
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.

Frequently asked questions

What is the best open-source MCP gateway in 2026?

There is no single best — it depends on your priority. ToolMesh leads on declarative REST→MCP via DADL (one file), token-efficient Code Mode, a built-in Output Gate/DLP, and a SQL audit trail, in a single Go binary. IBM ContextForge leads on multi-protocol breadth (MCP + A2A + REST/gRPC) and maturity (IBM-backed, 1.0). Docker MCP Gateway leads on running untrusted servers safely. Obot leads on product breadth (an end-user chat client). lunar.dev MCPX leads on observability and traffic control. ToolMesh, ContextForge, Obot, Docker, and MCPX are all self-hostable and MIT- or Apache-licensed.

Which MCP gateways can turn a REST API into MCP tools without writing a server?

Practically, ToolMesh is the one that does this at API scale: it describes a whole REST API in one declarative DADL file, which an LLM can generate from your OpenAPI spec. IBM ContextForge can expose REST endpoints too, but you register each endpoint as JSON by hand — there is no OpenAPI import yet (an open feature request as of March 2026), so a real enterprise API means hand-authoring dozens of tool definitions or scripting the conversion yourself. Its REST passthrough also passes the API key through as a caller-supplied parameter instead of injecting it server-side, so the credential is not hidden from the model. For both reasons we treat ContextForge's REST→MCP as partial, not equivalent to ToolMesh's. Obot, Docker MCP Gateway, and lunar.dev MCPX do not convert REST APIs at all — they run or aggregate existing MCP servers. In the wider market, Kong (commercial) and Unla (config-driven) also offer REST→MCP. Streaming, stateful, or unusual-auth APIs remain the exception for any approach.

ToolMesh vs IBM ContextForge — which should I choose?

They overlap on governance: both are self-hosted, Apache-2.0, with RBAC and pre/post output gating. The big practical difference is REST APIs. ToolMesh uses one declarative DADL file per API (LLM-generatable from OpenAPI) and always injects the credential server-side, so the model never sees it. ContextForge registers each REST endpoint as JSON by hand with no OpenAPI import — and its REST passthrough takes the API key as a caller-supplied tool parameter, so for those tools the credential is not hidden from the model. That makes ContextForge's REST→MCP practical for a handful of endpoints, not for a full enterprise API where hand-registration and credential isolation both matter (its server-side credential isolation does apply to its OAuth/MCP upstreams, just not to REST passthrough). Choose ContextForge for multi-protocol breadth (MCP + A2A + gRPC + agent routing), 1.0 maturity, and IBM backing. Choose ToolMesh for declarative spec-driven REST→MCP with server-side credentials, token-saving Code Mode, a SQL-queryable audit trail, and a single lightweight Go binary. ContextForge is broader and more mature; ToolMesh is the more practical, better-isolated REST→MCP path.

Is Obot open source?

Obot's core (obot-platform/obot) is MIT-licensed and self-hostable, but it is open-core: enterprise SSO (Okta, Microsoft Entra, Auth0, JumpCloud) is gated to the paid Enterprise edition; the free build supports Google and GitHub OAuth. ToolMesh and IBM ContextForge, by contrast, keep their governance features in the Apache-2.0 core with no paid tier.

Obot vs lunar.dev MCPX — how do they differ?

Both are MIT open-core, self-hostable gateways, but they lead with different strengths. Obot is a broad platform — it ships an end-user chat client, a registry, MCP-server hosting, and strong RBAC; much of its governance is in the open core, with enterprise SSO paid. lunar.dev MCPX is observability- and traffic-control-led (metrics, rate limiting), with deeper governance (SSO/RBAC, secret isolation, risk scoring) gated to Enterprise. Pick Obot for a complete user-facing product, MCPX for operational visibility across many agents. If you instead need declarative REST→MCP or a built-in DLP output gate, neither is the strongest fit — ToolMesh or IBM ContextForge cover that.

Docker MCP Gateway vs Obot — which is better?

They solve different problems. Docker MCP Gateway focuses on running third-party MCP servers safely: per-server container isolation, Docker-signed catalog images with SBOMs, and a large curated catalog — but with static access control (no per-user RBAC). Obot is a broader product with multi-role RBAC, credential isolation, an end-user chat client, and a managed-cloud option, but no container-isolation or signed-image story. Choose Docker for supply-chain-safe isolation in a Docker workflow; choose Obot for governance and a user-facing experience. Neither converts REST APIs into MCP tools — for that, see ToolMesh or IBM ContextForge.

Which MCP gateways have a built-in DLP or output gate?

ToolMesh ships a built-in Output Gate: goja-based policies that block confidential payloads before execution and redact PII after. IBM ContextForge ships a 40-plugin guardrail framework with PII Filter and Secrets Detection running pre- and post-invocation — a genuine analog. Docker MCP Gateway can block secrets/PII via --block-secrets but blocks rather than redacts. Obot documents request filtering/guardrails but no turnkey redaction. lunar.dev MCPX has no documented DLP in its core gateway (it lives in Lunar's separate product line).

Docker MCP Gateway vs ToolMesh — which should I choose?

Choose Docker MCP Gateway to run third-party MCP servers safely inside Docker: per-server container isolation, Docker-signed images with SBOMs, and a large curated catalog. Choose ToolMesh for governance and connectivity: declarative REST→MCP without writing a server, per-user authorization, a configurable Output Gate/DLP with redaction, and a SQL audit trail. They can be combined — ToolMesh can govern the MCP servers Docker runs.

lunar.dev MCPX vs ToolMesh — which should I choose?

Choose lunar.dev MCPX for operational visibility and traffic control across many agents: metrics, rate limiting, and — at the Enterprise tier — risk scoring and an evaluation sandbox. Choose ToolMesh for fail-closed governance in the open-source core: declarative REST→MCP (DADL), OpenFGA authorization, credential isolation, a built-in Output Gate, and a SQL audit trail. In MCPX several of these are Enterprise-tier or live in the separate Lunar Gateway.

Are there other MCP gateways worth considering?

Yes — this comparison focuses on five self-hostable open-source/open-core control planes, not the whole market. Also relevant: Microsoft MCP Gateway (Kubernetes routing), Stacklok ToolHive (container isolation + Cedar policy), Envoy AI Gateway and agentgateway (traffic/data-plane with MCP aggregation), Kong AI Gateway (commercial REST→MCP for Kong-managed APIs), Pomerium (zero-trust access proxy), MCPJungle (registry/gateway), and Unla (config-driven REST→MCP). Most of these run or proxy existing MCP servers rather than converting REST APIs; Kong and Unla are the other REST→MCP claimants.

Are these MCP gateways self-hostable and vendor-neutral?

Yes — all five can be self-hosted. ToolMesh runs as a single Go binary or Docker container (Apache 2.0). IBM ContextForge runs as a Python service on Docker/Kubernetes (Apache 2.0). Obot and lunar.dev MCPX run on Docker or Kubernetes (MIT, open-core). Docker MCP Gateway is MIT but requires a Docker/containerd runtime. ToolMesh and the open-source tiers of the others keep your tool definitions, credentials, and audit data inside your own environment.

Maintained by Dunkel Cloud GmbH, the team behind ToolMesh. Competitor facts are sourced from each project’s own documentation. Last updated: 29 June 2026 — the MCP-gateway category moves fast, so re-check current feature sets before deciding. Corrections welcome via GitHub.