agent-connector: MCPサーバー/フックを複数のエージェントCLIに一度にデプロイするツール

 (github.com/ken-jo)
1 ポイント 投稿者 kenjo 4 시간 전 | まだコメントはありません。 | WhatsAppで共有

現在の問題点: MCPサーバー/フックをエージェントCLIごとに個別対応しなければならない問題

MCPサーバーを複数のagent CLIに接続していくと、同じ設定を異なるフォーマットで何度も管理し続けることになります。

たとえば:

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

サーバー登録だけでも手間ですが、フックはさらに複雑です。
ホストごとにイベントモデルが異なるため、同じ動作でもCLIごとに再調整が必要になります。

そこで、この繰り返しを減らすために agent-connector を作りました。

解決方法

defineConnector()で一度定義すれば、各ホストが実際に読むネイティブ設定ファイルとしてレンダリングします。

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

中間ラッパーを実行したり独自フォーマットを強制したりする方式ではありません。
各CLIがもともと読むJSON、TOML、settingsファイルなどを生成する方式です。

対応範囲

現在はMCPサーバー登録だけでなく、以下の領域まで扱っています。

  • MCPサーバー登録
  • ホスト別フックイベントモデル変換
  • プラグイン / 拡張機能のパッケージング
  • 各ホストのマーケットプレイスのインストールフロー
  • 複数CLI向け一括インストール
  • uninstall --purgeによる残存設定の削除
  • ツールごとのトークンテレメトリ
  • SDKベースの独自ブランドCLI作成

ユーザーはおおむね次のように使います。

$ agent-connector install  
$ agent-connector uninstall --purge  
# または  
$ plugin install brand-name

現在の状況

今のところは一人で開発しています。

主に時間を使った部分は次のとおりです。

  • クロスホスト設定レンダリング
  • フックイベントモデルの正規化
  • プラグイン / 拡張機能のパッケージング
  • マーケットプレイスのインストールフロー
  • テレメトリ
  • Linux / macOS / Windowsテスト

現在、42個のagent CLIを対象に設定を生成できます。

検証してみたこと

実際のテストとして、既存のMCPである context-mode を移植してみました。

結果は次のとおりです。

  • ホスト別デプロイコード: 20,322行 → 76行
  • フックスクリプト: 71個 → 0個
  • 対応CLI: 15個 → 42個

ただし、これは自分で作ったMCPサーバーではなく、既存サーバーを移してみた事例です。
そのため、より多様なMCPサーバーで壊れるケースを見てみたいです。

求めているフィードバック

MCPサーバーを作っている方々に実際に試してもらい、フィードバックをいただけるととても助かります。

特に、次のようなフィードバックを求めています。

  • 特定のCLIで設定が壊れるケース
  • フックイベントモデルが不十分なケース
  • プラグイン / マーケットプレイスのフローで不自然な部分
  • API設計で使いづらい部分
  • OSSプロジェクト構造に対する指摘

MCPがagentに実際のツールを接続するレイヤーだとすれば、特定CLIの設定方式に振り回され続けない構造が必要だと考えています。

関連記事

まだコメントはありません。

まだコメントはありません。