Das Model Context Protocol hat gewonnen. Seit Anthropic es Ende 2024 als Open Source freigegeben hat, ist MCP auf 97 Millionen SDK-Downloads pro Monat und über 10.000 aktive Server angewachsen, dazu kommt vollwertige Unterstützung durch alle großen KI-Plattformen. Google setzt es ein. OpenAI setzt es ein. Die Linux Foundation verwaltet es inzwischen über die Agentic AI Foundation. Wenn Sie irgendetwas bauen, das einen KI-Agenten mit externen Tools verbindet, ist MCP Ihr Wire Protocol, ob Sie es wissen oder nicht.
Aber worüber auf den Feiern zu Ehren des Protokolls niemand spricht: MCP-Server im Alltag tatsächlich zu benutzen, ist immer noch erstaunlich mühsam.
Sie wollen einen Postgres-MCP-Server testen? JSON-Konfigurationsdatei bearbeiten. Client neu starten. Hoffen, dass der stdio-Transport nicht stillschweigend ausfällt. Sie wollen die Ausgabe eines Servers in einen anderen weiterleiten? Viel Glück: Jetzt schreiben Sie eigenen Glue Code für etwas, das eine Pipe sein sollte. Sie wollen wissen, welche Tools ein Server anbietet, bevor Sie ihn fix in den System-Prompt Ihres Agenten einbauen? Das macht dann einmal eine Runde durch die SDK-Dokumentation, vielen Dank auch.
Genau diese Lücke schließt mcpx. Es ist ein CLI-Wrapper, der aus jedem MCP-Server etwas macht, das sich wie ein wohlerzogenes Unix-Kommando benimmt.
Die Grundidee: einmal registrieren, überall aufrufen
Das mentale Modell ist bewusst einfach. Sie registrieren einen Server unter einem Alias:
mcpx add pg "npx @toolbox-sdk/server --prebuilt=postgres --stdio" \
-e POSTGRES_HOST=localhost \
-e POSTGRES_PASSWORD=secret
Ab dann ist jedes Tool dieses Servers über eine Slash-Command-Syntax erreichbar:
mcpx /pg execute_sql --params '{"sql": "SELECT count(*) FROM orders"}'
Das war’s. Sie pflegen keine eigenen Konfigurationsdateien pro Client mehr und müssen Claude Desktop oder Cursor nicht neu starten, wenn ein neuer Server dazukommt. Die Server-Registry liegt unter ~/.config/mcpx/servers.json und gilt für alle Aufrufe.
Wenn Sie bereits Server in Claude Desktop konfiguriert haben, liest mcpx import diese Konfiguration und registriert alles in einem Rutsch. Manuell migrieren müssen Sie nichts.
Zwei Zielgruppen, eine Schnittstelle
Das Design trifft eine bewusste Entscheidung, der die meisten Entwickler-Tools ausweichen: Es bedient Menschen und KI-Agenten über dieselbe Schnittstelle, ohne bei einer der beiden Abstriche zu machen.
Für Menschen bringt mcpx alles mit, was man von einem ordentlichen CLI-Tool erwartet. Jedes registrierte Tool bekommt ein --help, das zur Laufzeit aus seinem JSON Schema generiert wird. Mit --dry-run sehen Sie vorab, was ausgeführt würde. Eine interaktive REPL mit Fuzzy Search lässt Sie Server erkunden, ohne sich Tool-Namen merken zu müssen. Und die Ausgabe kommt wahlweise als Tabelle, YAML, CSV oder Markdown, denn nicht jeder will um 8 Uhr früh JSON lesen.
Für KI-Agenten liefert jedes Kommando ein deterministisches JSON-Envelope:
{"ok": true, "result": [{"type": "text", "text": "..."}]}
Es gibt kein HTML zu parsen und keine mehrdeutigen Antworten in natürlicher Sprache. Semantische Exit Codes (0 bis 5) sagen dem Agenten genau, was schiefgegangen ist: War es ein Verbindungsfehler, ein Validierungsfehler oder ein internes Serverproblem? Ein Agent kann allein anhand der Exit Codes verzweigen, ohne Fehlermeldungen zu parsen.
Dieser Ansatz für zwei Zielgruppen ist mehr als Ästhetik. Ein Mensch kann dadurch genau denselben Aufruf debuggen, den ein Agent ausführt. Wenn der MCP-Aufruf Ihres Agenten um 3 Uhr früh fehlschlägt, reproduzieren Sie ihn, indem Sie dasselbe mcpx-Kommando in Ihr Terminal kopieren. Das ist ein enormer operativer Vorteil gegenüber SDK-Aufrufen, die irgendwo im Code eines Agenten-Frameworks vergraben sind.
Komposition
Die einzelnen Features (Server-Registry, Schema-Introspektion, formatierte Ausgabe) sind Mindeststandard. Richtig stark wird es, wenn Sie anfangen, sie zu kombinieren.
Pipes über Servergrenzen hinweg
Weil mcpx über stdin/stdout kommuniziert, können Sie Tools völlig verschiedener Server mit ganz normalen Unix-Pipes verketten:
mcpx /pg execute_sql --params '{"sql":"SELECT id FROM users"}' \
| mcpx /pg get_column_cardinality --params-stdin
Das ist innerhalb von Agenten-Frameworks wirklich schwer umzusetzen. Die meisten MCP-Clients behandeln jeden Server als isolierte Verbindung. mcpx behandelt sie als kombinierbare Kommandos, nach demselben mentalen Modell, mit dem Sie seit Jahrzehnten grep, awk und jq verwenden.
YAML-Workflows
Für strukturiertere mehrstufige Abläufe unterstützt mcpx YAML-Workflow-Dateien mit Variableninterpolation zwischen den Schritten:
name: Daily Report
steps:
- server: pg
tool: execute_sql
params: { sql: "SELECT count(*) as n FROM orders WHERE date = current_date" }
output: count
- server: slack
tool: send_message
params: { text: "Orders today: {{count}}" }
Die Schritte laufen nacheinander ab. Mit output benennen Sie Ausgaben, mit {{variable}} verweisen Sie darauf. Sie brauchen kein Orchestrierungs-Framework und keinen DAG-Compiler, nur eine YAML-Datei und mcpx workflow pipeline.yaml.
Hooks und Observability
Mit Middleware-Hooks führen Sie Shell-Kommandos vor oder nach jedem Tool-Aufruf aus, per Pattern Matching auf Server- und Tool-Namen:
mcpx hook add 'before:pg.*' 'echo "$MCPX_TOOL" >> /var/log/mcpx.log'
mcpx hook add 'after:pg.execute_sql' 'notify-send "SQL executed"'
Zusammen mit dem NDJSON-Audit-Logging (--log) bekommen Sie vollständige Observability: was aufgerufen wurde, wann, mit welchen Parametern und wie lange es gedauert hat. Bei MCP-Deployments in Produktion ist das der Unterschied zwischen „auf meinem Rechner lief es“ und dem tatsächlichen Wissen, was Ihre Agenten tun.
Das Gateway: ein Endpunkt, sie alle zu knechten
Das architektonisch wohl bedeutendste Feature ist mcpx serve. Es fasst alle registrierten Server zu einem einzigen MCP-Endpunkt zusammen, erreichbar über stdio (für Claude Desktop, Cursor usw.) oder HTTP (für Remote-Agenten):
mcpx serve # stdio mode
mcpx serve --port 8080 # HTTP mode
Damit wird mcpx zu einem universellen MCP-Aggregator. Statt jeden Client einzeln mit jedem Server zu konfigurieren, richten Sie den Client auf mcpx, und mcpx übernimmt die Verteilung. Fügen Sie mcpx einen neuen Server hinzu, hat jeder verbundene Client sofort Zugriff darauf.
Für Organisationen, die über mehrere Teams hinweg mehrere MCP-Server betreiben, ist das eine deutliche Vereinfachung. Ein Gateway. Eine Konfiguration. Ein Ort für Hooks, Logging und Zugriffskontrolle.
Der Agent-Skill-Generator
Ein Detail verrät, dass das Tool von jemandem stammt, der tatsächlich Agenten in Betrieb nimmt: mcpx skills /server generiert aus dem Schema eines beliebigen Servers automatisch ein SKILL.md-Dokument.
mcpx skills /pg > SKILL-pg.md
Das Ergebnis ist eine strukturierte Markdown-Datei, die ein Agent als Kontext verwenden kann: Tool-Namen, Beschreibungen, Parameter-Schemas, Aufrufmuster, häufige Fehler. Solche Dokumentation kostet von Hand normalerweise einen Nachmittag und ist schon veraltet, wenn Sie sie committen. mcpx generiert sie in Sekunden aus dem Live-Schema.
Wenn Sie das Skills-System von Claude Code, das Project Knowledge von Claude Desktop oder ein beliebiges Agenten-Framework mit Kontextdateien verwenden, können Sie das direkt als fertige Dokumentation einsetzen.
Schema-Diffing: weil APIs driften
mcpx diff /server vergleicht die aktuellen Tool-Schemas mit einem gespeicherten Snapshot. Dieses kleine Feature löst ein echtes Produktionsproblem: MCP-Server werden aktualisiert, Tool-Signaturen ändern sich, und die Annahmen Ihres Agenten über Parameternamen stimmen still und leise nicht mehr.
Mit Schema-Diffing erkennen Sie solche Änderungen, bevor sie zur Laufzeit Fehler verursachen. Lassen Sie es in der CI laufen. Als Cron Job. Als Hook. Entscheidend ist: Bei MCP-Deployments in Produktion ist Schema-Stabilität ein Vertrag, und Verträge müssen durchgesetzt werden.
Performance und Architektur
Unter der Haube läuft bei mcpx ein Hintergrund-Daemon, der MCP-Serververbindungen über Unix Sockets (unter Windows Named Pipes) bündelt. Der Daemon startet bei der ersten Verwendung automatisch und beendet sich nach 5 Minuten Inaktivität von selbst, sodass keine Zombie-Prozesse entstehen und Sie den Lebenszyklus nicht von Hand verwalten müssen.
In der Praxis heißt das: Die Wiederverwendung von Verbindungen über den Daemon ist rund 39 % schneller, als für jeden Aufruf einen frischen MCP-Serverprozess zu starten. Lazy Import des MCP SDK spart 59 ms beim Laden der Module. Und das Single-Tool-Gateway-Muster senkt den Token-Overhead beim Betrieb über mcpx serve um 95 %.
Das sind keine Benchmarketing-Zahlen. Solche Optimierungen zählen, wenn ein Agent pro Aufgabe Dutzende Tool-Aufrufe macht und sich jede Latenz von 100 ms aufsummiert.
Was das für das MCP-Ökosystem bedeutet
Das MCP-Ökosystem tritt in das ein, was ich seine „Management-Phase“ nennen würde. Das Protokoll selbst ist gesetzt: Es steht unter dem Dach der Linux Foundation, die Spezifikation ist stabil, die SDKs sind ausgereift. Die schwierigen Probleme sind jetzt operativer Natur: Wie finden Sie Server, verwalten Verbindungen, beobachten Tool-Aufrufe, setzen Schemas durch und kombinieren Workflows über Server hinweg?
mcpx ist eine Antwort auf diese Probleme. Es nimmt die Unix-Philosophie (kleine Tools, die eine Sache gut machen und über Standardschnittstellen kombiniert werden) und wendet sie auf MCP an. Das Ergebnis ist ein Tool, das einzelnen Entwicklern beim Erkunden von MCP-Servern schon heute nützt und bis zu Deployments in Produktion skaliert, bei denen Observability und Zuverlässigkeit zählen.
Der Code ist in TypeScript geschrieben und MIT-lizenziert, und das erste Release (v0.1.0) ist ab sofort verfügbar.
npm install -g mcpx
Aus dem Englischen übersetzt: zum Originalbeitrag