MCP-Bench — 用真实 MCP Server 测 agent 工具编排
已复核 · 稳定内容MCP-Bench 是一个面向 tool-using LLM agents 的 benchmark。它把 agent 连接到 28 个真实 MCP server、约 250 个工具，任务覆盖金融、旅行、科学计算、学术搜索等 domain。
类比：过去很多 tool benchmark 像让学生用一把指定螺丝刀拧一个螺丝；MCP-Bench 更像把学生带进工具间，给一个模糊任务，让他自己找扳手、量尺、说明书，并按正确顺序完成。
论文强调的难点不是单次 function call，而是跨工具协调、参数控制、轨迹规划和中间结果 grounding。
早期工具调用 benchmark 常把工具名、参数位置和任务边界都说得很清楚，agent 只要把自然语言翻译成一次 function call 就能得分。
MCP-Bench 关心的是更接近真实 MCP 生态的问题：用户不会告诉你该用哪个 server，工具之间有输入输出依赖，中间结果还必须被可靠地带到下一步。
换句话说，它测的不是“会不会 call tool”，而是“能不能在工具森林里找到路线”。这也是 MCP 从协议层进入产品层后最容易暴露的能力缺口。
MCP 让工具接入变标准化，但标准化不等于 agent 会用。真实 MCP 环境有三个困难：
- 工具名不一定直接出现在用户请求里。
- 一个 MCP server 里多个工具常常需要组合使用。
- 跨 server 工作流会产生强输入输出依赖。
所以只测“会不会调用指定工具”太乐观。MCP-Bench 把评估推进到“能不能从模糊目标里找工具、排步骤、用中间结果继续推进”。
MCP-Bench 的评估框架分三层：
| 层级 | 测什么 |
|---|---|
| tool-level | 是否理解 schema、参数和工具用途 |
| trajectory-level | 是否能规划多步调用顺序 |
| task completion | 最终结果是否满足目标 |
这个分层和 agent-planning-benchmark-2026 是互补的：APB 更偏计划诊断，MCP-Bench 更偏真实工具编排。
手工 toy 复现
Section titled “手工 toy 复现”任务：“找一篇关于 vector database 的论文，取第一作者，再查这个作者最近的机构。”
可用工具有 academic_search、paper_detail、author_profile、calendar_lookup。
| 步骤 | 正确轨迹 | 常见失败 |
|---|---|---|
| 1 | 用 academic_search 找论文 | 直接猜论文名 |
| 2 | 用 paper_detail 取作者列表 | 把摘要里的名字当作者 |
| 3 | 用 author_profile 查机构 | 跳到无关工具 |
| 4 | 引用中间结果回答 | 没有 grounding |
这个 toy 的关键是：工具调用不是孤立点，而是一条带数据依赖的轨迹。第二步的 paper id 是第三步的输入来源。
- MCP server 多不等于能力强：工具越多，检索和选择越容易出错。
- schema 理解只是第一关：会填参数不代表能规划跨工具流程。
- live server 带来可复现压力：真实服务更接近生产，但版本、网络和数据变化会影响复现实验。
MCP-Bench 让我把 MCP benchmark 看成三件事的组合：工具发现、轨迹规划、结果 grounding。缺任何一环，agent 都可能看起来“会调用工具”，但做不完任务。
对 study 的 agent 知识图来说，这篇应该和 toolformer、react、agent-planning-benchmark-2026 连起来读：工具学习、执行循环和规划诊断共同决定 tool agent 的上限。
- 原文：https://arxiv.org/abs/2508.20453
- 代码与数据：https://github.com/Accenture/mcp-bench
- toolformer：工具使用训练路线。
- react：工具调用循环的经典 prompt 范式。