# ToolMesh vs Obot, Docker MCP Gateway, MCPX & IBM ContextForge > Ein ehrlicher Vergleich self-hostbarer Open-Source-MCP-Gateways 2026: ToolMesh, IBM ContextForge, Obot, Docker MCP Gateway und lunar.dev MCPX — Lizenz, Autorisierung, Credential-Isolation, Output-Gating/DLP, Audit, REST-zu-MCP und Token-Effizienz. Canonical: https://www.toolmesh.io/de/mcp-gateway-comparison/ Ein praxisnaher, belegter Vergleich self-hostbarer Open-Source-**MCP-Gateways** (auch MCP-Control-Planes genannt): **ToolMesh**, **IBM ContextForge**, **Obot**, **Docker MCP Gateway** und **lunar.dev MCPX**. Wir entwickeln ToolMesh — sieh dies also als Anbieter-Vergleich. Aber jede Aussage über ein anderes Projekt verlinkt dessen eigene Dokumentation, und wir benennen, wo die anderen ehrlich stärker oder reifer sind. Wenn dir etwas Falsches auffällt, [öffne ein Issue](https://github.com/DunkelCloud/ToolMesh/issues). Dies ist **kein vollständiger Marktüberblick** — der Fokus liegt auf fünf self-hostbaren, Open-Source-/Open-Core-Control-Planes. Eine kurze [Liste weiterer relevanter Gateways](#weitere-relevante-gateways) (Microsoft, ToolHive, Envoy, Kong, Pomerium u. a.) steht am Ende. Sie unterscheiden sich am stärksten darin, **wie viel Governance im Open-Source-Kern steckt**, und darin, **wie man Tools hinzufügt**: ToolMesh verwandelt eine ganze REST-API aus einer deklarativen DADL-Datei in MCP-Tools (per LLM aus OpenAPI erzeugbar). IBM ContextForge kann REST-Endpoints ebenfalls als Tools exponieren, aber jeden einzeln von Hand als JSON, ohne OpenAPI-Import — für eine reale API ist das eher ein theoretischer als ein praktikabler Weg. Die anderen betreiben oder proxien MCP-Server, die man bereits hat. :::note[Neu bei REST-APIs? Was ist ein „Endpoint"?] Eine REST-API stellt jede Funktion als eigenen **Endpoint** bereit — „Issues auflisten", „einen Pull Request erstellen", „einen User abrufen" und so weiter. Reale APIs haben viele davon: allein GitHubs REST-API umfasst mehrere Hundert (ToolMeshs GitHub-DADL deckt rund 250 in einer einzigen Datei ab). Genau diese Größenordnung ist der Grund, warum es darauf ankommt, *wie* ein Gateway REST in MCP-Tools verwandelt — eine ganze API einmal in einer deklarativen Datei zu beschreiben ist ein völlig anderer Aufwand, als eine JSON-Definition pro Endpoint von Hand zu schreiben. ::: ## Kurzfassung — eine Zeile je Tool - **ToolMesh** — Eine governance-first Control-Layer (einzelnes Go-Binary). Verwandelt nahezu jede REST-API aus einer deklarativen YAML-Datei ([DADL](/de/dadl/)) in gesteuerte MCP-Tools, mit Per-Tool-/Per-User-[Autorisierung](/de/authorization/), Runtime-[Credential-Injection](/de/authentication/), eingebautem [Output Gate](/de/output-gate/) (DLP), SQL-Audit-Trail und token-sparendem [Code Mode](/de/code-mode/) — alles im Apache-2.0-Kern. Am besten, wenn *deklaratives REST→MCP*, *token-effiziente Discovery* und *ein leichter Footprint* zählen. - **IBM ContextForge** — Das breiteste Open-Source-Gateway: föderiert MCP **+ A2A + REST/gRPC** hinter einem Endpoint, mit starkem RBAC, verschlüsselten Per-User-Credentials und einem 40-Plugin-Guardrail-/DLP-Framework. IBM-gestützt, gerade bei 1.0. Am besten, wenn du Multi-Protokoll-Breite und Enterprise-Reife brauchst — und einen Python-Stack sowie Per-Endpoint-Tool-Registrierung in Kauf nimmst. - **Obot** — Eine breite MCP-Plattform, die zusätzlich einen End-User-Chat-Client (RAG, Tasks) liefert. Starkes RBAC und Credential-Isolation; ein Teil des Enterprise-SSO ist kostenpflichtig. Am besten, wenn du ein vollständiges, nutzerseitiges Produkt willst. - **Docker MCP Gateway** — Die stärkste Antwort darauf, *nicht vertrauenswürdige MCP-Server sicher zu betreiben*: Container-Isolation pro Server, Docker-signierte Catalog-Images, großer kuratierter Katalog. Am besten, wenn Supply-Chain-Sicherheit und Docker-native DX Priorität haben. - **lunar.dev MCPX** — Observability- und traffic-control-geprägt (Rate-Limiting, Metriken; Risk-Scoring ist Enterprise). Am besten, wenn operative Sichtbarkeit über viele Agenten Priorität hat. ## Vergleich auf einen Blick Die Tabelle nutzt **Ja / Teilweise / Nein** (klarer als Symbole — für Leser wie KI-Assistenten); die Tool-Abschnitte erläutern jedes „Teilweise". Auf schmalen Bildschirmen scrollt sie horizontal. | Fähigkeit | ToolMesh | ContextForge | Obot | Docker MCP | MCPX | | --- | --- | --- | --- | --- | --- | | Kern-Lizenz | Apache 2.0 | Apache 2.0 | MIT (Open-Core) | MIT (Gateway) | MIT (Open-Core) | | Self-Host-Runtime | Go-Binary | Python | Docker / K8s | Braucht Docker-Daemon | Docker / K8s | | REST-API → MCP, ohne Server | **Ja — deklaratives DADL (eine Datei)** | Teilweise — manuell, pro Endpoint | Nein | Nein | Nein | | Feingranulare Per-User-Autz | Ja — OpenFGA/ReBAC | Ja — RBAC + Scoping | Ja — RBAC | Teilweise (statisch) | Teilweise (Enterprise) | | Credentials vor LLM verborgen | Ja | OAuth: ja; REST-Tools: nein | Ja | Ja (Docker Secrets) | Ja (Enterprise) | | Eingebautes Output Gate / DLP | Ja — Policies + Redaktion | Ja — PII-/Secret-Plugins | Teilweise (Filterung) | Teilweise (`--block-secrets`) | Teilweise (nicht nativ) | | Audit-Trail | Ja — SQL-abfragbar | Teilweise — Logs + OTel | Ja — Per-Call-Log | Teilweise (Logs+Tracing) | Ja — Logs+Metriken | | Token-Effizienz / Code Mode | Ja — Code Mode | Teilweise — Kompression | Nein | Ja — `code-mode` (exp.) | Ja — dynamische Discovery | | Caller-/Agent-Trust-Tiers | Ja — CallerClass | Teilweise (RBAC) | Teilweise (RBAC) | Nein | Teilweise (per Agent) | | Container-Isolation pro Server | Nein | Nein | Teilweise | **Ja — signiert + SBOM** | Nein | | Multi-Protokoll (A2A / gRPC) | Nein (MCP + REST) | **Ja — MCP+A2A+gRPC** | Nein | Nein | Nein | | Kuratierter Server-Katalog | Nein (DADL-Registry) | Nein (eigene Registry) | Ja | Ja — 200+ Tools | Ja | | End-User-Chat-Client | Nein | Nein | **Ja (+ RAG, Tasks)** | Nein | Nein | Ehrliches Fazit: **Kein einzelnes Tool gewinnt jede Zeile.** ToolMesh und ContextForge überlappen stark bei der *Governance* (RBAC, Credential-Isolation, Output-Gating) — aber bei REST→MCP unterscheiden sie sich deutlich: ToolMesh ist deklarativ und spec-getrieben (eine Datei, skaliert auf eine ganze API), während ContextForges Per-Endpoint-JSON-Registrierung sich für eine große API nicht realistisch skalieren lässt, ohne ein eigenes Konversions-Skript zu schreiben. ToolMesh führt zudem bei Code Mode und einem leichten Single-Binary-Footprint; ContextForge bei Protokoll-Breite (A2A/gRPC) und Reife; Docker bei Container-Isolation; Obot bei Produktbreite; MCPX bei Observability. ## Wann welches wählen - **Wähle ToolMesh** für deklaratives, spec-getriebenes REST→MCP (eine DADL-Datei, per LLM aus OpenAPI erzeugbar), token-sparenden Code Mode, Per-Tool-/Per-User-Autorisierung, ein eingebautes Output Gate mit Redaktion und einen SQL-Audit-Trail — in einem einzigen Go-Binary, vollständig offenem Kern. - **Wähle IBM ContextForge** für **Multi-Protokoll-Breite** (MCP + A2A + REST/gRPC + Agent-Routing) und Enterprise-Reife (RBAC, SSO, 40-Plugin-Guardrails, IBM-Backing) — wenn du REST-Tools Endpoint für Endpoint registrierst und einen Python-Dienst betreibst. - **Wähle Obot** für ein vollständiges, nutzerseitiges Produkt (Chat-Client, Self-Service-Katalog, RBAC, Managed Cloud) — mit Enterprise-SSO als kostenpflichtigem Add-on. - **Wähle Docker MCP Gateway**, um Drittanbieter-MCP-Server sicher in Docker zu betreiben: Container-Isolation, signierte Images, großer Katalog. - **Wähle lunar.dev MCPX** für operative Sichtbarkeit und Traffic-Kontrolle über viele Agenten — mit Enterprise für die tiefere Governance. Du kannst sie auch kombinieren: ToolMesh kann vor MCP-Servern sitzen, die Docker, Obot oder ContextForge betreibt, und seine eigenen Autorisierungs-, Credential-, Gating- und Audit-Schichten darüberlegen. ## ToolMesh [ToolMesh](https://github.com/DunkelCloud/ToolMesh) ist eine Apache-2.0-, self-hosted Control-Layer (einzelnes Go-Binary). Sein Alleinstellungsmerkmal ist **[DADL](/de/dadl/)** — eine deklarative YAML-Sprache, die nahezu jede REST-API aus **einer Datei** in gesteuerte MCP-Tools verwandelt, ohne pro API einen Server zu schreiben; ein LLM kann die DADL aus deiner OpenAPI-Spec erzeugen. Jeder Tool-Call läuft durch eine Pipeline: authentifizieren → autorisieren → Credentials injizieren → ausführen → Output prüfen und redigieren → auditieren. Die Pipeline ist fail-closed für Authentifizierung und jedes aktivierte Gate; die OpenFGA-Autorisierung ist fail-closed im Restrict-Modus (Default ist Bypass). - **Autorisierung:** per Tool, per User über OpenFGA (User→Plan→Tool), erzwungen im Restrict-Modus. - **Credentials:** serverseitig aus einem pluggable CredentialStore injiziert; das Modell sieht sie nie. - **Output Gate (DLP):** deterministische goja-basierte JS-Policies, die vor der Ausführung laufen (blockieren) und danach (PII redigieren). Layer 1 heute, weitere Layer in Entwicklung. - **Audit:** ein SQL-abfragbarer Trail — jeder Call einem User, Plan und Caller zugeordnet. - **Code Mode:** komprimiert einen großen Tool-Katalog auf rund 1.000 Tokens — in unserem Katalog etwa 142× weniger (≈142.000 → ~1.000), skalierend mit der Katalog-Größe — plus progressive, BM25-basierte Tool-Discovery, sodass die Kontextkosten konstant bleiben. - **Caller-Trust-Tiers:** unterscheidet, *welcher* KI-Client aufrief (trusted / standard / untrusted), und stuft PII-Filterung und Tool-Zugriff entsprechend. **Wo ToolMesh schwächer ist (zur Kenntnis):** keine Container-Isolation pro Server, kein signierter Image-Katalog, kein End-User-Chat-Client und — anders als ContextForge — kein A2A/gRPC. Es ist Early-Stage (vor 1.0) mit geringer öffentlicher Adoption. Seine ehrlichen Vorteile sind das *deklarative Ein-Datei*-REST→MCP-Modell, Code Mode und der leichte Single-Binary-Footprint. ## IBM ContextForge [IBM ContextForge](https://github.com/IBM/mcp-context-forge) (MCP Context Forge; Apache-2.0, ~4k Stars, Python) ist der direkteste Open-Source-Konkurrent hier — und der breiteste. Es föderiert **MCP, A2A und REST/gRPC** hinter einem gesteuerten Endpoint, routet zu A2A-/OpenAI-/Anthropic-Agenten und erreichte **1.0 GA im Juni 2026** mit IBM im Rücken. Bei der Governance ist es auf oder nahe ToolMesh-Niveau: - **Starkes RBAC** — Token-Scoping plus Action-RBAC (`platform_admin`/`team_admin`/`developer`/`viewer`), Per-Tool-Berechtigungen, mandantenfähige Teams, SSO (Entra/Okta/Keycloak/OIDC). - **Credentials vor dem LLM verborgen — aber nur für OAuth-/MCP-Upstreams.** Diese Secrets sind verschlüsselt at rest, per Gateway und per User gespeichert, serverseitig angewandt. Ein über [Passthrough](https://ibm.github.io/mcp-context-forge/latest/using/rest-passthrough/) registrierter REST-Endpoint ist anders: sein API-Key reist als **Caller-gelieferter Tool-Parameter**, der auf einen Header gemappt wird (`"apiKey": "secret123"` wird zu `X-API-Key: secret123`) — für REST-Tools wird das Credential also *nicht* serverseitig injiziert oder vor dem Modell verborgen, anders als bei ToolMeshs DADL, wo der Server es immer injiziert. - **Guardrails/DLP über ein 40-Plugin-Framework** — PII-Filter (maskiert SSN/Karten/E-Mails auf Input *und* Output), Secrets-Detection, OPA-/Cedar-Policy, LLMGuard — pre und post. Ein echtes Output-Gate-Äquivalent. - **Observability** — strukturiertes JSON-Logging + OpenTelemetry-Tracing; produktive K8s-/Redis-Föderation; airgapped Admin-UI. **Unterschiede zu ToolMesh — die praktische REST→MCP-Lücke:** „ContextForge macht REST→MCP auch" braucht einen harten Vorbehalt. ToolMesh beschreibt eine ganze API einmal in einer deklarativen DADL-Datei (Spec als Source of Truth, per LLM aus OpenAPI erzeugbar). ContextForge registriert Tools **Endpoint für Endpoint als JSON** über die Admin-API, und es gibt **keinen OpenAPI-Spec-Import** (ein [offenes Feature-Request](https://github.com/IBM/mcp-context-forge/discussions/3466) Stand März 2026) — das Onboarding einer realen Unternehmens-API bedeutet also, ein Tool pro Endpoint von Hand zu verfassen oder die OpenAPI→JSON-Konvertierung selbst zu skripten, was der Maintainer selbst als Workaround vorschlägt. Für eine API mit Dutzenden oder Hunderten Endpoints ist das eine wesentliche Lücke, keine Gleichwertigkeit. Schlimmer noch: Der Passthrough nimmt den Upstream-API-Key als **Caller-gelieferten Tool-Parameter**, statt ihn serverseitig zu injizieren — der REST→MCP-Pfad gibt damit auch die Credential-Isolation auf, einen Kerngrund, überhaupt ein Gateway vor eine API zu setzen. ContextForge hat zudem **kein Code-Mode-/Sandbox-Äquivalent** und keine progressive/semantische Tool-Discovery, sein Audit ist log/OTel-basiert (kein klar dokumentiertes abfragbares Audit-API), und es läuft ein schwererer Python-Stack vs. ToolMeshs einzelnes Go-Binary. Wo ContextForge klar stärker ist: **A2A- + gRPC-Breite, Agent-Routing, 1.0-Reife und IBMs Backing.** ## Obot [Obot](https://github.com/obot-platform/obot) (von Obot AI, ehemals Acorn Labs; Gründer aus dem Rancher-/SUSE-Umfeld; 35 Mio. $ Seed 2025) ist das breiteste *Produkt*: über das Gateway hinaus liefert es eine **Registry, MCP-Server-Hosting und einen End-User-Chat-Client** mit RAG, Projekt-Memory und geplanten Tasks. - **Starkes RBAC**, gescoped pro Katalog, Server und Tool; Policies decken User, Gruppen und Agenten ab. - **Credential-Isolation ist ein Headline-Claim** — Agenten sehen nie rohe Credentials. - **Per-Call-Audit** und **Composite MCP Servers** (Backends zu einem virtuellen Server kombinieren). **Unterschiede zu ToolMesh:** Obots Kern ist MIT, aber **Open-Core** — Enterprise-SSO (Okta/Entra/Auth0/JumpCloud) ist dem Bezahl-Tier vorbehalten. Wir fanden **kein deklaratives REST→MCP**, **kein Turnkey-DLP** (Request-Filtering/Guardrails, keine Redaktion) und **keine Code-Mode-artige Kompression**. Wo Obot stärker ist: ein nutzbares End-User-Produkt und, als dediziertes MCP-Startup, das bestfinanzierte der Gruppe. ## Docker MCP Gateway [Docker MCP Gateway](https://github.com/docker/mcp-gateway) (MIT, Go) ist das Runtime-Stück von Dockers MCP-Geschichte (Catalog = signierte Images auf Docker Hub; Toolkit = Docker-Desktop-UI; Gateway = der OSS-Proxy). Herausragende Stärken: - **Container-Isolation pro Server** mit eingeschränkten Privilegien — die stärkste Isolations-Story hier. - **Signierte Catalog-Images + SBOMs** — die meisten Catalog-Server sind Docker-built mit Attestations und signierten SBOMs, erzwungen via `--verify-signatures`. - **Serverseitige Secret-Injection** + ein `--block-secrets`-Interceptor; eine `code-mode`-Funktion, die Docker als **experimentell** markiert („noch nicht zuverlässig für den allgemeinen Einsatz"). **Unterschiede zu ToolMesh:** Die Autorisierung ist **statisch** (kein Per-User/RBAC/Caller-Identity); **kein deklaratives REST→MCP**; Output-Kontrolle ist Secret-**Blockierung, keine Redaktion**; und das Modell **hängt von einer Docker-/containerd-Runtime ab**. Docker ist die bessere Antwort für das *Isolieren nicht vertrauenswürdiger Server*. ## lunar.dev MCPX [lunar.dev MCPX](https://github.com/TheLunarCompany/lunar) (MIT, TypeScript) stammt aus Lunar.devs API-Gateway-/Observability-Herkunft. (Nicht der nVIDIA-„MCPX"-Xbox-Chip.) - **Observability** — eingebaute Metriken (Prometheus-kompatibel, aus Lunars Gateway-Linie) + ein niedriger Overhead-Claim (~4 ms p99). - **Traffic-Kontrolle** — Rate-Limiting, Retries, Circuit Breaker. - **Risk-Scoring + Evaluation-Sandbox** für nicht vertrauenswürdige Server — beide **Enterprise-Tier**. - **Dynamische Tool-Discovery** (`defer_loading`) für Token-Effizienz. **Unterschiede zu ToolMesh:** Ein Großteil der tieferen Governance ist **Enterprise-Tier** (SSO/RBAC, Secret-Isolation, Risk-Scoring); die Open-Source-Zugriffskontrolle ist UI-/Profil-Toggle, keine Policy-Engine; **DLP ist kein dokumentiertes MCPX-Feature** (es liegt in Lunars separater Gateway-Linie); Audit ist Logs + Metriken, kein SQL; und MCPX **aggregiert bestehende MCP-Server** — kein REST→MCP. Wo MCPX stärker ist: Observability und Traffic-Kontrolle. ## Weitere relevante Gateways Nicht im direkten Vergleich (anderer Scope, kommerziell oder kleiner), aber wissenswert, wenn du den Markt sondierst: - **[IBM ContextForge](https://github.com/IBM/mcp-context-forge)** — oben behandelt; es *ist* im Hauptvergleich. - **[Microsoft MCP Gateway](https://github.com/microsoft/mcp-gateway)** (MIT) — Kubernetes-nativer Reverse-Proxy für session-aware Routing und Lifecycle-Management bestehender MCP-Server. Routet/orchestriert; konvertiert keine REST-APIs. - **[Stacklok ToolHive](https://github.com/stacklok/toolhive)** (Apache-2.0-Kern + kommerzielles Enterprise) — sicherheitsfokussiert: jeder MCP-Server im eigenen Container mit Cedar-Policy-Autz, OIDC und Audit. Betreibt bestehende Server; kein REST→MCP. - **[Envoy AI Gateway](https://aigateway.envoyproxy.io/)** (Apache-2.0) — Envoy/CNCF-nahes LLM-Traffic-Gateway, das MCP-Aggregation *hinzufügte* (`MCPRoute`, OAuth, Tool-Filterung). Aggregiert; kein REST→MCP. - **[agentgateway](https://agentgateway.dev/)** (Apache-2.0, Linux Foundation) — Data-Plane für MCP/A2A mit RBAC und Tool-Föderation; bewirbt das Exponieren einer OpenAPI-API als Tool, aber Föderation ist der Kern. - **[Kong AI Gateway](https://developer.konghq.com/plugins/ai-mcp-proxy/)** (kommerziell/Enterprise) — sein AI-MCP-Proxy-Plugin konvertiert Kong-gemanagte REST-APIs in MCP-Tools mit Kongs Policies. Das nächste Enterprise-Analog zu ToolMeshs REST→MCP, aber kostenpflichtig und auf bereits in Kong onboardete APIs beschränkt. - **[Pomerium](https://www.pomerium.com/)** (Apache-2.0 + Managed) — identity-aware Zero-Trust-Proxy; frontet MCP-Server mit OAuth und Tool-Level-Access-Policy. Steuert Zugriff; erstellt keine Tools. - **[MCPJungle](https://github.com/mcpjungle/MCPJungle)** (MPL-2.0) — self-hosted Registry + Gateway für mehrere MCP-Server. Aggregiert; kein REST→MCP. - **[Unla](https://github.com/AmoyLab/Unla)** (MIT) — leichtes Go-Gateway, das bestehende APIs und MCP-Server per Konfiguration in MCP-Server verwandelt (REST/gRPC). Mit Kong der andere echte REST→MCP-Claimant — config-datei-getrieben statt deklarative-Spec-plus-Governance, und ein kleineres Solo-Org-Projekt.