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

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.

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

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) in gesteuerte MCP-Tools, mit Per-Tool-/Per-User-Autorisierung, Runtime-Credential-Injection, eingebautem Output Gate (DLP), SQL-Audit-Trail und token-sparendem 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 ist eine Apache-2.0-, self-hosted Control-Layer (einzelnes Go-Binary). Sein Alleinstellungsmerkmal ist 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 (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 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 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 (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 (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 (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 — oben behandelt; es ist im Hauptvergleich.
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 (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 (Apache-2.0) — Envoy/CNCF-nahes LLM-Traffic-Gateway, das MCP-Aggregation hinzufügte (MCPRoute, OAuth, Tool-Filterung). Aggregiert; kein REST→MCP.
agentgateway (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 (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 (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 (MPL-2.0) — self-hosted Registry + Gateway für mehrere MCP-Server. Aggregiert; kein REST→MCP.
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.

Häufige Fragen

Was ist das beste Open-Source-MCP-Gateway 2026?

Es gibt kein einzelnes bestes — es hängt von deiner Priorität ab. ToolMesh führt bei deklarativem REST→MCP über DADL (eine Datei), token-effizientem Code Mode, eingebautem Output Gate/DLP und SQL-Audit-Trail, in einem einzigen Go-Binary. IBM ContextForge führt bei Multi-Protokoll-Breite (MCP + A2A + REST/gRPC) und Reife (IBM-gestützt, 1.0). Docker MCP Gateway führt beim sicheren Betrieb nicht vertrauenswürdiger Server. Obot führt bei der Produktbreite (End-User-Chat-Client). lunar.dev MCPX führt bei Observability und Traffic-Kontrolle. ToolMesh, ContextForge, Obot, Docker und MCPX sind alle self-hostbar und MIT- oder Apache-lizenziert.

Welche MCP-Gateways können eine REST-API ohne Server-Schreiben in MCP-Tools verwandeln?

Praktisch ist ToolMesh dasjenige, das das auf API-Ebene leistet: es beschreibt eine ganze REST-API in einer deklarativen DADL-Datei, die ein LLM aus deiner OpenAPI-Spec erzeugen kann. IBM ContextForge kann REST-Endpoints ebenfalls exponieren, aber man registriert jeden Endpoint von Hand als JSON — es gibt noch keinen OpenAPI-Import (offenes Feature-Request Stand März 2026), eine reale Unternehmens-API bedeutet also Dutzende Tool-Definitionen von Hand oder ein eigenes Konversions-Skript. Sein REST-Passthrough reicht den API-Key zudem als Caller-gelieferten Parameter durch, statt ihn serverseitig zu injizieren — das Credential ist also nicht vor dem Modell verborgen. Aus beiden Gründen werten wir ContextForges REST→MCP als teilweise, nicht als gleichwertig zu ToolMeshs. Obot, Docker MCP Gateway und lunar.dev MCPX konvertieren gar keine REST-APIs — sie betreiben oder aggregieren bestehende MCP-Server. Im weiteren Markt bieten auch Kong (kommerziell) und Unla (config-getrieben) REST→MCP. Streaming-, Stateful- oder ungewöhnliche Auth-APIs bleiben bei jedem Ansatz die Ausnahme.

ToolMesh vs IBM ContextForge — was sollte ich wählen?

Sie überlappen bei der Governance: beide sind self-hosted, Apache-2.0, mit RBAC und Pre-/Post-Output-Gating. Der große praktische Unterschied sind REST-APIs. ToolMesh nutzt eine deklarative DADL-Datei pro API (per LLM aus OpenAPI erzeugbar) und injiziert das Credential immer serverseitig, das Modell sieht es nie. ContextForge registriert jeden REST-Endpoint von Hand als JSON ohne OpenAPI-Import — und sein REST-Passthrough nimmt den API-Key als Caller-gelieferten Parameter, für diese Tools ist das Credential also nicht vor dem Modell verborgen. Das macht ContextForges REST→MCP praktikabel für eine Handvoll Endpoints, nicht für eine vollständige Unternehmens-API, bei der Hand-Registrierung und Credential-Isolation beide zählen (seine serverseitige Credential-Isolation gilt für OAuth-/MCP-Upstreams, nur nicht für REST-Passthrough). Wähle ContextForge, wenn du Multi-Protokoll-Breite (MCP + A2A + gRPC + Agent-Routing), 1.0-Reife und IBM-Backing brauchst. Wähle ToolMesh für deklaratives spec-getriebenes REST→MCP mit serverseitigen Credentials, token-sparenden Code Mode, einen SQL-abfragbaren Audit-Trail und ein einziges leichtes Go-Binary. ContextForge ist breiter und reifer; ToolMesh ist der praktikablere, besser isolierte REST→MCP-Weg.

Ist Obot Open Source?

Obots Kern (obot-platform/obot) ist MIT-lizenziert und self-hostbar, aber es ist Open-Core: Enterprise-SSO (Okta, Microsoft Entra, Auth0, JumpCloud) ist der kostenpflichtigen Enterprise-Edition vorbehalten; der freie Build unterstützt Google- und GitHub-OAuth. ToolMesh und IBM ContextForge halten ihre Governance-Funktionen dagegen im Apache-2.0-Kern, ohne kostenpflichtiges Tier.

Obot vs lunar.dev MCPX — wie unterscheiden sie sich?

Beide sind MIT-Open-Core, self-hostbare Gateways, führen aber mit unterschiedlichen Stärken. Obot ist eine breite Plattform — es liefert einen End-User-Chat-Client, eine Registry, MCP-Server-Hosting und starkes RBAC; ein Großteil der Governance liegt im offenen Kern, Enterprise-SSO ist kostenpflichtig. lunar.dev MCPX ist observability- und traffic-control-geprägt (Metriken, Rate-Limiting), mit tieferer Governance (SSO/RBAC, Secret-Isolation, Risk-Scoring) im Enterprise-Tier. Wähle Obot für ein vollständiges nutzerseitiges Produkt, MCPX für operative Sichtbarkeit über viele Agenten. Brauchst du stattdessen deklaratives REST→MCP oder ein eingebautes DLP-Output-Gate, ist keines von beiden die stärkste Wahl — das decken ToolMesh oder IBM ContextForge ab.

Docker MCP Gateway vs Obot — was ist besser?

Sie lösen unterschiedliche Probleme. Docker MCP Gateway fokussiert auf den sicheren Betrieb von Drittanbieter-MCP-Servern: Container-Isolation pro Server, Docker-signierte Catalog-Images mit SBOMs und einen großen kuratierten Katalog — aber mit statischer Zugriffskontrolle (kein Per-User-RBAC). Obot ist ein breiteres Produkt mit Multi-Rollen-RBAC, Credential-Isolation, End-User-Chat-Client und Managed-Cloud-Option, aber ohne Container-Isolation oder signierte Images. Wähle Docker für supply-chain-sichere Isolation in einem Docker-Workflow; wähle Obot für Governance und ein nutzerseitiges Erlebnis. Keines konvertiert REST-APIs in MCP-Tools — dafür siehe ToolMesh oder IBM ContextForge.

Welche MCP-Gateways haben ein eingebautes DLP oder Output Gate?

ToolMesh liefert ein eingebautes Output Gate: goja-basierte Policies, die vertrauliche Payloads vor der Ausführung blockieren und PII danach redigieren. IBM ContextForge liefert ein 40-Plugin-Guardrail-Framework mit PII-Filter und Secrets-Detection pre und post — ein echtes Äquivalent. Docker MCP Gateway kann Secrets/PII über --block-secrets blockieren, aber blockiert statt zu redigieren. Obot dokumentiert Request-Filtering/Guardrails, aber keine Turnkey-Redaktion. lunar.dev MCPX hat kein dokumentiertes DLP in seinem Kern-Gateway (es liegt in Lunars separater Produktlinie).

Docker MCP Gateway vs ToolMesh — was sollte ich wählen?

Wähle Docker MCP Gateway, um Drittanbieter-MCP-Server sicher in Docker zu betreiben: Container-Isolation pro Server, Docker-signierte Images mit SBOMs und einen großen kuratierten Katalog. Wähle ToolMesh für Governance und Konnektivität: deklaratives REST→MCP ohne Server-Schreiben, Per-User-Autorisierung, ein konfigurierbares Output Gate/DLP mit Redaktion und einen SQL-Audit-Trail. Sie lassen sich kombinieren — ToolMesh kann die MCP-Server steuern, die Docker betreibt.

lunar.dev MCPX vs ToolMesh — was sollte ich wählen?

Wähle lunar.dev MCPX für operative Sichtbarkeit und Traffic-Kontrolle über viele Agenten: Metriken, Rate-Limiting und — im Enterprise-Tier — Risk-Scoring und eine Evaluation-Sandbox. Wähle ToolMesh für Fail-Closed-Governance im Open-Source-Kern: deklaratives REST→MCP (DADL), OpenFGA-Autorisierung, Credential-Isolation, ein eingebautes Output Gate und einen SQL-Audit-Trail. In MCPX sind mehrere davon Enterprise-Tier oder liegen im separaten Lunar Gateway.

Gibt es weitere erwägenswerte MCP-Gateways?

Ja — dieser Vergleich fokussiert auf fünf self-hostbare Open-Source-/Open-Core-Control-Planes, nicht den ganzen Markt. Ebenfalls relevant: Microsoft MCP Gateway (Kubernetes-Routing), Stacklok ToolHive (Container-Isolation + Cedar-Policy), Envoy AI Gateway und agentgateway (Traffic-/Data-Plane mit MCP-Aggregation), Kong AI Gateway (kommerzielles REST→MCP für Kong-gemanagte APIs), Pomerium (Zero-Trust-Access-Proxy), MCPJungle (Registry/Gateway) und Unla (config-getriebenes REST→MCP). Die meisten betreiben oder proxien bestehende MCP-Server, statt REST-APIs zu konvertieren; Kong und Unla sind die anderen REST→MCP-Claimanten.

Sind diese MCP-Gateways self-hostbar und anbieterneutral?

Ja — alle fünf lassen sich self-hosten. ToolMesh läuft als einzelnes Go-Binary oder Docker-Container (Apache 2.0). IBM ContextForge läuft als Python-Dienst auf Docker/Kubernetes (Apache 2.0). Obot und lunar.dev MCPX laufen auf Docker oder Kubernetes (MIT, Open-Core). Docker MCP Gateway ist MIT, benötigt aber eine Docker-/containerd-Runtime. ToolMesh und die Open-Source-Tiers der anderen halten deine Tool-Definitionen, Credentials und Audit-Daten in deiner eigenen Umgebung.

Gepflegt von Dunkel Cloud GmbH, dem Team hinter ToolMesh. Fakten zu Mitbewerbern stammen aus deren eigener Dokumentation. Zuletzt aktualisiert: 29. Juni 2026 — die MCP-Gateway-Kategorie bewegt sich schnell, prüfe daher aktuelle Feature-Sets vor einer Entscheidung neu. Korrekturen willkommen über GitHub.