MCP BatchIt

MCP BatchIt

将多个 MCP 工具调用批量合并为单个“batch_execute”请求，从而减少 AI 代理的开销和令牌使用量。

目录

1. 介绍
2. 为什么使用 BatchIt
3. 主要功能和限制
4. 安装和启动
5. 多阶段使用
   • 实施阶段
     • 信息收集
     • LLM 专用步骤（列出代码定义）
     • 文档创建
6. 常问问题
7. 执照

介绍

⚠️注意：工作正在进行中

该项目正在积极开发，以解决几个复杂的挑战：

• 保持与现有 MCP 服务器的向后兼容性
• 解决多连接客户端的传输复杂性（Cline、Roo、Claude Desktop）
• 创建适合初学者的实现

虽然功能齐全，但随着我们完善解决方案，预计还会不断改进和变化。

MCP BatchIt是模型上下文协议 (MCP)生态系统中的一个简单聚合器服务器。它只对外暴露一个工具： batch_execute 。您无需在单独的消息中调用多个 MCP 工具（例如fetch 、 read_file 、 create_directory 、 write_file等），而是可以在一个聚合器请求中将它们批量处理。

这大大减少了 AI 代理或 LLM 对话中的令牌使用、网络开销和重复上下文。

为什么使用 BatchIt

• 每条消息一个操作问题：通常，LLM 或 AI 代理一次只能调用一个 MCP 工具，从而迫使多步骤任务进行多次调用。
• 过多的往返：10 个单独的文件操作可能需要 10 条消息 → 10 个响应。
• BatchIt 的方法：
  1. 接受单个batch_execute请求。
  2. 在后台生成（或连接）实际目标 MCP 服务器（如文件系统服务器）。
  3. 并行运行每个子操作（工具调用），直至maxConcurrent 。
  4. 如果一个子操作失败并且stopOnError为真，它会停止新的子操作。
  5. 返回一个合并的 JSON 结果。

主要功能和限制

特征

1. 单一“批量执行”工具
   • 您只需指定引用现有 MCP 服务器工具的子操作列表。
2. 并行执行
   • 由maxConcurrent控制，同时运行多个子操作。
3. 超时和错误停止
   • 每个子操作都会竞争timeoutMs ，如果一个操作失败，您可以跳过剩余的操作。
4. 连接缓存
   • 重复使用与下游 MCP 服务器的相同连接进行重复调用，在空闲超时后关闭。

限制

1. 批次中途无数据传递
   • 如果子操作 #2 依赖于 #1 的输出，则进行多次聚合器调用。
2. 没有部分进展
   • 在每个“batch_execute”结束时，您将获得所有子操作的结果。
3. 必须使用真实的 MCP 服务器
   • 如果您生成或连接到聚合器本身，您将看到“未找到工具”。聚合器只有“batch_execute”。
4. 每次呼叫一个目标服务器
   • 每个聚合器调用都引用单个目标 MCP 服务器。如果您需要多个服务器，则需要使用更高级的逻辑或单独调用。

安装和启动

BatchIt 默认在STDIO上启动，以便您的 AI 代理（或任何 MCP 客户端）可以启动它。例如：

您现在可以向其发送 JSON-RPC 请求（ tools/call method, name= "batch_execute" ）。

记忆库

使用 Cline/Roo 代码，您可以利用 Nick Baumann 开发的强大的“记忆库”自定义指令来构建上下文项目文档框架。

查看存储库文档

传统方法（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调用来实现的：

注意：聚合器生成@modelcontextprotocol/server-filesystem （通过npx ）来执行并行read_file操作。

LLM 专用步骤（列出代码定义）

此阶段涉及聚合器外部的处理，通常使用 LLM 或 AI 代理功能：

此步骤使用 Roo Code 的list_code_definition_names工具，该工具仅供 LLM 使用。不过，请注意，许多 MCP 服务器可以提供类似的功能，因此无需 LLM 请求即可完成此过程。

文档创建

最后阶段结合前面步骤的数据（文件内容和代码定义）在memory-bank目录中生成文档：

聚合器按顺序处理这些操作（ maxConcurrent=1 ），创建目录并写入多个文档文件。结果数组指示每个操作的成功/失败状态。

常问问题

问题 1：如果子操作 #2 依赖于子操作 #1 的结果，我是否需要多次聚合器调用？ 是的。BatchIt不会在同一请求中的子操作之间传递数据。您可以进行多阶段调用（如上例所示）。

**问题 2：为什么我有时会收到“未找到工具 create_directory”的提示？**这是因为您的transport可能指向的是聚合器脚本本身，而不是真正的 MCP 服务器。请确保引用类似@modelcontextprotocol/server-filesystem内容。

**问题 3：我可以实现并发并发加上 stopOnError 吗？**当然可以。如果一个子操作失败，我们就跳过启动新的子操作。已经运行的子操作会并行完成。

**问题 4：BatchIt 每次都会重新生成目标服务器吗？**如果指定keepAlive: false ，则可以。但是，如果您使用完全相同的targetServer.name + transport ，它会缓存连接，直到空闲超时为止。

**问题 5：如果中间发生错误，是否会返回部分结果？**是的。错误发生之前完成的每个子操作以及失败的子操作都会包含在最终聚合器响应中。如果stopOnError为 true，则剩余的子操作将被跳过。

执照

麻省理工学院