ContextForge: eine föderierte Gateway-Lösung für MCP-, A2A- und REST/gRPC-APIs
Ein AI-Gateway, eine Registrierung und ein Proxy, die sich vor allen MCP-, A2A- oder REST/gRPC-APIs befinden und einen einheitlichen Endpunkt mit zentralisierter Erkennung, Leitplanken und Verwaltung bereitstellen. Optimiert Agenten- und Tool-Aufrufe und unterstützt Plugins.
Auf einen Blick
- Was ist das?
- Eine Open-Source-Registry und ein Proxy, die KI-orientierte Protokolle hinter einem einzigen Endpunkt vereinen, mit Governance, Schutzmechanismen und Beobachtbarkeit.
- Für wen ist es gedacht?
- ContextForge ist ein unter Apache 2.0 lizenziertes Python-Projekt, das MCP-, A2A- und REST/gRPC-Dienste hinter einer einzigen Registry und einem Proxy bündelt. Es bietet ein Gateway, das als konformer MCP-Server agiert, eine Admin-Oberfläche und mehrere Bereitstellungspfade von einem einzelnen PyPI-Paket bis zu einem Kubernetes-Helm-Chart.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was das Repository tatsächlich enthält · ibm mcp context forge
Das README beschreibt ContextForge als eine Open-Source-Registry und einen Proxy, die Model-Context-Protocol-(MCP-)Server, A2A-Server sowie REST- oder gRPC-APIs in einem einzigen Endpunkt für KI-Clients zusammenführen. Das zentrale Artefakt ist ein Python-Paket, das als mcp-contextforge-gateway auf PyPI veröffentlicht wird. Das Repository selbst enthält die FastAPI-Anwendung unter mcpgateway/, eine Testsuite, die das README mit über 7.000 Tests beziffert, Helm-Charts, ein Plugin-Framework und eine mit MkDocs erstellte Dokumentationsseite. Die Repository-Metadaten weisen 4.247 Sterne und 800 Forks aus; der Standardzweig ist main.
Die drei Gateway-Ebenen und das Plugin-Modell
Das README gliedert das Gateway in drei Ebenen. Das Tools-Gateway übernimmt MCP, REST und die Übersetzung von gRPC zu MCP mit TOON-Komprimierung. Das Agent-Gateway routet A2A-Protokollverkehr sowie OpenAI-kompatible und Anthropic-Agentenaufrufe. Das API-Gateway bietet Ratenbegrenzung, Authentifizierung, Wiederholungen und einen Reverse-Proxy für REST-Dienste. Darüber hinaus unterstützt das Projekt laut README mehr als 40 Plugins für zusätzliche Transporte, Protokolle und Integrationen. Die Plugins werden nicht namentlich aufgelistet; die Überprüfung des Katalogs erfordert einen Blick in das plugins/-Verzeichnis oder die Dokumentation.
Die Einrichtung beginnt mit zwei Pflicht-Geheimnissen
Die Schnellstartanleitung stellt klar, dass JWT_SECRET_KEY und AUTH_ENCRYPTION_SECRET in jeder Umgebung erforderlich sind, einschließlich der lokalen Entwicklung, und dass das Gateway ohne sie nicht startet. Der dokumentierte erste Schritt ist die Ausführung von python3 -m mcpgateway.scripts.init_secrets, um Werte in .env.secrets zu erzeugen, die dann exportiert werden. Python 3.11 oder neuer wird als Voraussetzung genannt. Das README merkt außerdem an, dass das Gateway beim Start sofort mit einem Pydantic-Validierungsfehler abbricht, wenn eine erforderliche .env-Variable fehlt oder ungültig ist, und dass Platzhalter wie __REPLACE_ME__ abgelehnt werden.
Bereitstellungspfade von PyPI bis Kubernetes
Vier Bereitstellungswege sind dokumentiert. Der PyPI-Weg installiert mcp-contextforge-gateway in eine virtuelle Umgebung und führt den Befehl mcpgateway aus. Ein einzelner Docker-Container wird als ghcr.io/ibm/mcp-context-forge auf GHCR veröffentlicht und kann mit Docker oder Podman betrieben werden; das README weist darauf hin, dass arm64-Produktionsimages derzeit nicht unterstützt werden. Docker Compose startet einen vollständigen Stack mit PostgreSQL, Redis, nginx und drei Gateway-Replikaten. Ein Helm-Chart unter charts/mcp-stack ermöglicht die Bereitstellung auf Kubernetes mit Autoskalierung, Prometheus-Metriken und RBAC. Für jeden Weg wiederholt das README dieselbe Anforderung: Echte Geheimnisse müssen erzeugt sein, bevor das Gateway bootet.
Konfiguration, Sicherheitsstandards und Inhaltslimits
Die Konfigurationsdokumentation verweist auf eine .env.example-Datei und eine Referenz, die laut README mehr als 300 Umgebungsvariablen abdeckt. Zwei Variablen haben unsichere Standardwerte, die das README vor dem Produktionsbetrieb zu ändern empfiehlt: BASIC_AUTH_USER ist standardmäßig admin, PLATFORM_ADMIN_EMAIL standardmäßig admin@example.com. Drei Sicherheitseinstellungen sind standardmäßig aktiv: REQUIRE_JTI, REQUIRE_TOKEN_EXPIRATION und PUBLIC_REGISTRATION_ENABLED auf false. Für Ressourcen und Prompts gelten Inhaltsgrößenlimits von standardmäßig 100 KB bzw. 10 KB; das README merkt an, dass die Limits nur für neue Erstell- und Aktualisierungsvorgänge gelten. Für die UAID-Routing zwischen Gateways gilt standardmäßig Fail-Closed: Eine leere Domänen-Allowlist blockiert jegliches Routing.
Beobachtbarkeit und die Admin-Oberfläche
Das README beschreibt eine mit HTMX 2.0.3 und Alpine.js erstellte Admin-Oberfläche mit einer Echtzeit-Logansicht, die Filterung, Suche und Export unterstützt; die Authentifizierung erfolgt über Basic, JWT oder eigene Schemata. Die Beobachtbarkeit wird über OpenTelemetry mit OTLP-Protokoll abgewickelt; als Backends werden Phoenix, Jaeger, Zipkin, Tempo, DataDog und New Relic genannt. Das Projekt beansprucht automatische Instrumentierung von Tools, Prompts, Ressourcen und Gateway-Operationen und bezeichnet das Tracing als anbieterunabhängig. Das README sagt außerdem, dass die Beobachtbarkeit bei Deaktivierung ohne Overhead sei, definiert aber nicht, wie das gemessen wird.
Die Warnung zu Beispiel-Servern und der Testumfang
Das Repository enthält ein Verzeichnis mcp-servers/, dessen Charakter das README unmissverständlich benennt: nicht unterstützte Beispiel- und Testserver, die größtenteils aus Community-Beiträgen stammen und denen in der Regel Sitzungsverwaltung, persistenter Zustand, Multi-Tenancy und Authentifizierung fehlen; sie sollten nicht in der Produktion ausgeführt werden. Das README warnt davor, nicht vertrauenswürdige MCP-Server direkt im lokalen Dateisystem auszuführen, und empfiehlt Sandboxing oder Container. Auf der Entwicklungsseite listet das README make-Ziele für Tests, Linting und Coverage und beziffert die Testsuite auf über 7.000 Tests. Die Lizenz ist Apache 2.0, die Urheberrechts- und Patentlizenzen für Nutzung, Vervielfältigung und Verbreitung gewährt; zu Support, Gewährleistung oder Sicherheitslage sagt sie nichts.
Redaktionelles Fazit
ContextForge ist ein unter Apache 2.0 lizenziertes Python-Projekt, das MCP-, A2A- und REST/gRPC-Dienste hinter einer einzigen Registry und einem Proxy bündelt. Es bietet ein Gateway, das als konformer MCP-Server agiert, eine Admin-Oberfläche und mehrere Bereitstellungspfade von einem einzelnen PyPI-Paket bis zu einem Kubernetes-Helm-Chart. Zum Zeitpunkt der Erstellung verzeichnet das Repository 4.247 Sterne und 800 Forks bei 1.204 offenen Issues. Das README nennt weder eine formale Support-SLA noch eine Produktionshistorie. Die Dokumentationsseite unter ibm.github.io/mcp-context-forge ist die Referenz für Konfiguration, Bereitstellung und Roadmap-Details. Die Entscheidung sollte sich auf diese konkreten Projektbedingungen stützen.
Community-Notizen