agent-connector: Ein Tool, um MCP-Server/Hooks auf einmal für mehrere Agent-CLIs bereitzustellen

 (github.com/ken-jo)
1 Punkte von kenjo 4 시간 전 | Noch keine Kommentare. | Auf WhatsApp teilen

Das aktuelle Problem: MCP-Server/Hooks müssen für jede Agent-CLI separat angepasst werden

Wenn man MCP-Server an mehrere Agent-CLIs anbinden will, muss man dieselbe Konfiguration immer wieder in unterschiedlichen Formaten pflegen.

Zum Beispiel:

  • Claude Code: JSON mcpServers
  • Codex: TOML [mcp_servers.*]
  • Cursor: mcp.json + hooks.json
  • Gemini: .gemini/settings.json

Schon die Server-Registrierung ist umständlich, bei Hooks wird es noch komplexer.
Da sich das Event-Modell je nach Host unterscheidet, muss selbst dasselbe Verhalten für jede CLI erneut angepasst werden.

Um diese Wiederholung zu verringern, habe ich agent-connector entwickelt.

Lösungsansatz

Definiert man es einmal mit defineConnector(), wird es in die nativen Konfigurationsdateien gerendert, die der jeweilige Host tatsächlich liest.

defineConnector({  
  server,  
  hooks,  
  plugins,  
  marketplace,  
})

Es ist kein Ansatz, bei dem ein Zwischen-Wrapper ausgeführt oder ein proprietäres Format erzwungen wird.
Stattdessen werden die JSON-, TOML-, Settings-Dateien usw. erzeugt, die jede CLI ursprünglich liest.

Unterstützter Umfang

Derzeit geht es nicht nur um die Registrierung von MCP-Servern, sondern auch um die folgenden Bereiche.

  • Registrierung von MCP-Servern
  • Umwandlung hostspezifischer Hook-Event-Modelle
  • Plugin-/Extension-Paketierung
  • Marketplace-Installationsabläufe der einzelnen Hosts
  • Sammelinstallation für mehrere CLIs
  • Entfernen verbleibender Konfigurationen über uninstall --purge
  • Tool-spezifische Token-Telemetrie
  • Erzeugung einer eigenen gebrandeten CLI auf SDK-Basis

Nutzer verwenden es ungefähr so.

$ agent-connector install  
$ agent-connector uninstall --purge  
# oder  
$ plugin install brand-name

Aktueller Stand

Bis jetzt entwickle ich es allein.

Der Großteil der Zeit ist in die folgenden Bereiche geflossen.

  • Host-übergreifendes Konfigurations-Rendering
  • Normalisierung von Hook-Event-Modellen
  • Plugin-/Extension-Paketierung
  • Marketplace-Installationsabläufe
  • Telemetrie
  • Tests unter Linux / macOS / Windows

Aktuell können Konfigurationen für 42 Agent-CLIs erzeugt werden.

Was ich getestet habe

In einem realen Test habe ich das bestehende MCP context-mode portiert.

Das Ergebnis sieht so aus.

  • Host-spezifischer Bereitstellungscode: 20.322 Zeilen → 76 Zeilen
  • Hook-Skripte: 71 → 0
  • Unterstützte CLIs: 15 → 42

Allerdings ist das kein MCP-Server, den ich selbst erstellt habe, sondern ein Fall, bei dem ich einen bestehenden Server übertragen habe.
Deshalb möchte ich auch Fälle sehen, in denen es bei verschiedensten MCP-Servern zu Problemen kommt.

Gesuchtes Feedback

Es wäre eine große Hilfe, wenn Leute, die MCP-Server bauen, das selbst ausprobieren und Feedback geben.

Insbesondere würde ich gern solches Feedback bekommen.

  • Fälle, in denen die Konfiguration in einer bestimmten CLI kaputtgeht
  • Fälle, in denen das Hook-Event-Modell nicht ausreicht
  • Unstimmige Stellen in Plugin-/Marketplace-Abläufen
  • Unbequeme Punkte im API-Design
  • Hinweise zur OSS-Projektstruktur

Wenn MCP die Schicht ist, die Agenten tatsächlich mit Tools verbindet, dann braucht es meiner Meinung nach eine Struktur, die nicht ständig von der Konfigurationsweise einer bestimmten CLI abhängig ist.

Verwandte Beiträge

Noch keine Kommentare.

Noch keine Kommentare.