ai-conductor 1.0 kann Server neu starten

Transparenz vorweg, wie beim letzten Mal: ai-conductor ist ein eigenes Projekt aus derselben Werkstatt wie KIberblick, gebaut von Patrick Cornelißen. Wir schreiben hier über unser eigenes Werkzeug und halten uns entsprechend mit Lob zurück.

Im Juni haben wir ai-conductor vorgestellt: ein lokaler Proxy, der sich zwischen Claude und die eigentlichen MCP-Server schiebt, damit man Server zur Laufzeit dazuschalten und wieder rauswerfen kann, ohne den Client neu zu starten. Damals stand die npm-Version bei 0.2.0. Seit heute liegt 1.0.0 auf npm.

Was sich seit Juni geändert hat

Neustart, ohne die Konfiguration zu beschädigen

Im Juni-Artikel stand als offene Schwäche: Stürzt ein Downstream-Server ab, gibt es keinen Weg, ihn gezielt wieder hochzuholen. In der Praxis half nur remove_server und danach add_server. Das ist heikler, als es klingt. remove_server löscht die gespeicherte Definition, und add_server baut sie aus dem wieder auf, was man frisch eintippt. Wer dabei eine Umgebungsvariable oder ein Argument vergisst, hat die Definition dauerhaft kaputtgemacht, ohne es zu merken.

restart_server nimmt den umgekehrten Weg: Es liest die Definition aus der Konfiguration und schreibt nie zurück. Die Konfiguration ist hier Quelle, nicht Ziel. Kommt der Server nicht hoch, wird der Zustand gemeldet statt eine Ausnahme geworfen, und die Definition bleibt auch dann erhalten.

Dazu kommt ein einzelner automatischer Wiederholungsversuch, wenn der Verbindungsaufbau scheitert. Der greift nur bei stdio-Servern, weil dort der zweite Anlauf einen frischen Prozess startet und damit einen beim Start verunglückten Server einfängt. Bei http und sse läuft der Server fremd, ein Neuversuch von hier ändert an dessen Zustand nichts, also sparen wir uns die doppelte Wartezeit. Bewusst genau ein Versuch, kein Backoff, keine Schleife. Abschalten lässt sich das pro Server über autoRetry: false, bestehende Konfigurationen brauchen nichts, das Feld wird beim Laden mit dem Default gefüllt.

Server suchen statt eintippen

Schon im Juni kam mit 0.3.0 ein zweiter Block dazu, über den wir bisher nicht geschrieben haben: Downstream-Server lassen sich in MCP-Registries suchen und direkt installieren, über die Meta-Tools list_registries, search_registry und install_from_registry.

Standardquelle ist die offizielle Registry unter registry.modelcontextprotocol.io. Dort gibt es strukturierte Startangaben, und es ist markiert, welche Geheimnisse ein Server braucht. Deshalb funktionieren dort sowohl das automatische Verbinden als auch die Erkennung nötiger Zugangsdaten. Glama ist nur eine Fundstelle: Die Einträge nennen kein ausführbares Kommando, man nimmt das Suchergebnis also als Vorlage und legt den Server danach von Hand an. Fällt eine Quelle aus, steht das im Suchergebnis, statt die ganze Suche abzuräumen.

Node 24 ist Pflicht

Die 1.0 ist auch deshalb eine 1.0, weil sie einen Bruch enthält: Die Node-Basis geht von 20 auf 24. Seit dem 30.04.2026 bekommt Node 20 keine Sicherheitspatches mehr, und ein Proxy, der Zugangsdaten aus dem Schlüsselbund reicht, sollte nicht auf einer Laufzeit ohne Patches stehen. Wer noch auf Node 20 oder 22 arbeitet, bleibt bis zum Wechsel auf 0.3.0.

Gleichzeitig sind die Abhängigkeiten durchgezogen worden, unter anderem zod 4, vitest 5, TypeScript 7 und das MCP SDK 1.30. Vorher standen 37 offene Dependabot-Meldungen zu 34 verschiedenen Advisories im Repo, eine davon als kritisch eingestuft. Jetzt sind es keine.

Dazu gehört ein Teil, den wir nicht größer machen wollen, als er war: Fast alle diese Meldungen hingen am HTTP-Server-Stack, den das MCP SDK als reguläre Abhängigkeit mitschleppt, und den lädt ai-conductor nie. Im gebauten Bundle findet sich keine Spur von express, hono, ajv oder qs, und die kritische Meldung betraf vitest, also ein reines Testwerkzeug. Ausnutzbar war da nichts. Behoben ist es trotzdem, weil die Pakete beim Nutzer auf der Platte landen und in dessen npm audit auftauchen. Bei einem Proxy, der Zugangsdaten verwaltet, ist das ein Vertrauensproblem, auch wenn der Code tot ist.

Dazu gibt es zum ersten Mal eine CI, die bei Pull Requests überhaupt etwas prüft: Node 24 und 26 auf Linux, dazu je ein Lauf auf Windows und macOS, weil Prozessstart, Pfade und der Schlüsselbund auf den drei Systemen unterschiedlich funktionieren.

Am Einstieg ändert sich nichts:

claude mcp add conductor -s user -- npx -y mcp-proxy-conductor

Ehrlicher Stand

1.0 heißt hier: Die Schnittstelle ist stabil genug, dass ein Bruch ab jetzt einen Major-Sprung kostet. Es heißt nicht, dass alles gelöst ist. Was offen bleibt:

• Ein Downstream, der die Verbindung offenhält, aber nicht mehr arbeitet, meldet weiterhin connected. Nichts merkt das, Aufrufe laufen in einen toten Server, bis man ihn selbst neu startet. Ein Wiederholungsversuch auf der Aufrufebene würde das lösen, dürfte dann aber nicht versehentlich Tool-Aufrufe wiederholen, die keine Wiederholung vertragen. Deshalb ist es nicht gebaut.
• Die Änderungsbenachrichtigungen sind unverändert grob: Bei jeder Änderung wird dem Client alles als geändert gemeldet.
• HTTP-Downstreams fallen nicht automatisch auf SSE zurück, der Transporttyp bleibt explizit.
• Multi-Tenant-Betrieb steht weiter auf der Liste und ist weiter nicht gebaut.

Wer wissen will, was MCP überhaupt ist, findet das in unserem Grundlagen-Artikel zum Model Context Protocol. Der Code liegt offen auf GitHub, Rückmeldungen gern dort.