MCP バッチイット

複数の MCP ツール呼び出しを単一の「batch_execute」リクエストにバッチ処理することで、AI エージェントのオーバーヘッドとトークンの使用量を削減します。

目次

1. 導入

2. BatchItを使用する理由

3. 主な機能と制限

4. インストールと起動

5. マルチフェーズの使用

   • 実装フェーズ

     • 情報収集

     • LLM のみのステップ (コード定義のリスト)

     • ドキュメント作成

6. よくある質問

7. ライセンス

導入

⚠️注意: 作業中

このプロジェクトは、いくつかの複雑な課題に対処するために積極的に開発されています。

• 既存のMCPサーバーとの下位互換性を維持

• マルチ接続クライアントによるトランスポートの複雑さの解決 (Cline、Roo、Claude Desktop)

• 初心者に優しい実装の作成

機能的には問題ありませんが、ソリューションを改良していく中で、継続的な改善と変更が予想されます。

MCP BatchItは、モデルコンテキストプロトコル（MCP）エコシステムにおけるシンプルなアグリゲータサーバーです。公開するツールは**batch_executeのみです。複数のMCPツール（ 個別のメッセージで呼び出すのではなく、1つのアグリゲータリクエストでまとめて処理**できます。

これにより、AI エージェントまたは LLM 会話におけるトークンの使用量、ネットワーク オーバーヘッド、および繰り返しコンテキストが大幅に削減されます。

BatchItを使用する理由

• メッセージごとに 1 つのアクションの問題: 通常、LLM または AI エージェントは一度に 1 つの MCP ツールしか呼び出せないため、複数ステップのタスクに対して複数回の呼び出しが強制されます。

• 過剰なラウンドトリップ: 10 個の個別のファイル操作では、10 個のメッセージ → 10 個の応答が必要になる場合があります。

• BatchItのアプローチ：

  1. 単一のbatch_executeリクエストを受け取ります。

  2. 実際のターゲット MCP サーバー (ファイルシステム サーバーなど) をバックグラウンドで生成 (または接続) します。

  3. 各サブ操作 (ツール呼び出し) をmaxConcurrentまで並列に実行します。

  4. 1 つのサブオペレーションが失敗し、 stopOnErrorが true の場合、新しいサブオペレーションは停止します。

  5. 1 つの統合された JSON 結果を返します。

主な機能と制限

特徴

1. 単一の「バッチ実行」ツール

   • 既存の MCP サーバーのツールを参照するサブオペレーションのリストを指定するだけです。

2. 並列実行

   • maxConcurrentによって制御され、複数のサブオペレーションを一度に実行します。

3. タイムアウトとエラー時の停止

   • 各サブオペレーションはtimeoutMsと競合し、1 つのオペレーションが失敗した場合は残りのオペレーションをスキップできます。

4. 接続キャッシュ

   • 繰り返しの呼び出しには下流の MCP サーバーへの同じ接続を再利用し、アイドル タイムアウト後に閉じます。

制限事項

1. バッチの途中でデータが渡されない

   • サブオペレーション #2 が #1 の出力に依存する場合は、複数のアグリゲータ呼び出しを実行します。

2. 部分的な進歩なし

   • 各「batch_execute」の最後に、すべてのサブオペレーションの結果がまとめて取得されます。

3. 実際のMCPサーバーを使用する必要があります

   • アグリゲータ自体を起動または接続すると、「ツールが見つかりません」というメッセージが表示されます。アグリゲータには「batch_execute」しかありません。

4. 1回の呼び出しにつき1つのターゲットサーバー

   • 各アグリゲータ呼び出しは、単一のターゲットMCPサーバーを参照します。複数のサーバーを参照したい場合は、より高度なロジックを使用するか、呼び出しを分割する必要があります。

インストールと起動

BatchItはデフォルトでSTDIOで起動するため、AIエージェント（または任意のMCPクライアント）から起動できます。例：

これで、JSON-RPC リクエスト ( tools/call method、 name= "batch_execute" ) を送信できるようになりました。

メモリバンク

Cline/Roo コードを使用すると、Nick Baumann が開発した強力な「Memory Bank」カスタム命令を活用して、コンテキスト プロジェクト ドキュメントのフレームワークを構築できます。

メモリバンクのドキュメントを見る

従来のアプローチ（19回以上の通話）:

1. package.json を読む

2. 応答を待つ

3. README.mdを読む

4. 応答を待つ

5. コード定義をリストする

6. 応答を待つ

7. メモリバンクディレクトリを作成する

8. 応答を待つ

9. productContext.md を書く

10. systemPatterns.md を書く

11. techContext.mdを書く

12. progress.md を書き込む

13. activeContext.md を書く

14. 応答を待つ（さらに 5 件の呼び出し）

合計: 約 19 個の個別の API 呼び出し (13 個の操作 + 6 個の応答待機)

BatchItアプローチ（1～3回の呼び出し）

マルチフェーズの使用

リアルタイム出力を必要とする複雑な複数ステップのタスク（ファイルの読み取りやドキュメントの生成など）を扱う場合、プロセスを明確なフェーズで処理する必要があります。これは、 BatchIt では同一リクエスト内のサブオペレーション間でのデータの受け渡しがサポートされていないためです。

実装フェーズ

情報収集

この初期フェーズでは、必要なファイル（例： package.json 、 README.md ）を読み込んでファイルシステムから情報を収集します。これは、ファイルシステムMCPサーバーへのbatch_execute呼び出しによって実行されます。

注: アグリゲータは、並列read_file操作を実行するために、 @modelcontextprotocol/server-filesystem ( npx経由) を生成し、

LLM のみのステップ (コード定義のリスト)

このフェーズでは、通常、LLM または AI エージェントの機能を使用して、アグリゲータ外部での処理が行われます。

このステップでは、LLM専用ツールであるRoo Codeのlist_code_definition_namesを使用します。ただし、多くのMCPサーバーが同様の機能を提供しているため、LLMリクエストなしでこのプロセスを完了することも可能です。

ドキュメント作成

最後のフェーズでは、前のステップのデータ (ファイルの内容とコード定義) を組み合わせて、 memory-bankディレクトリにドキュメントを生成します。

アグリゲータはこれらの操作を順番に（ maxConcurrent=1 ）処理し、ディレクトリを作成し、複数のドキュメントファイルを書き込みます。結果の配列は、各操作の成功/失敗ステータスを示します。

よくある質問

Q1: サブオペレーション #2 がサブオペレーション #1 の結果に依存する場合、複数のアグリゲータ呼び出しが必要ですか？ はい。BatchItは、同じリクエスト内でサブオペレーション間でデータの受け渡しを行いません。上記の例のように、マルチフェーズ呼び出しを行う必要があります。

Q2: 「Tool create_directory not found」というエラーメッセージが表示されることがあります。これは、 transport実際のMCPサーバーではなく、アグリゲータスクリプト自体を参照している可能性があるためです。 @modelcontextprotocol/server-filesystemのようなファイルを参照していることを確認してください。

**Q3: 並行処理に加えて stopOnError も実行できますか？**もちろんです。サブオペレーションが失敗した場合、新しいサブオペレーションの起動はスキップされます。すでに実行中のサブオペレーションは並列で終了します。

Q4: BatchItはターゲットサーバーを毎回再起動しますか？ keepAlive: falseを指定すれば再起動できます。ただし、 targetServer.name + transport全く同じにした場合、アイドルタイムアウトが経過するまで接続がキャッシュされます。

**Q5: 途中でエラーが発生した場合、部分的な結果が返されますか？**はい。エラー発生前に完了した各サブオペレーションは、失敗したサブオペレーションと共に、最終的なアグリゲーターのレスポンスに含まstopOnErrorます。stopOnError が true の場合、残りのサブオペレーションはスキップされます。

ライセンス

マサチューセッツ工科大学