现有工具调用基准要么用模拟工具、只校验「选对没选对」，要么靠检索器只挂几十个工具。 论文用 65 个 MCP 服务器、552 个真实可执行工具拼出约 147k token 的工具 schema，再用三种挂载模式控制工具规模。 结果：12 个模型里只有 3 个在工具更多时反而更准，其余全部下滑——尤其那些被 API 工具数上限逼着改用「提示词式函数调用」的模型。
工具调用评测长期卡在「假工具」和「小工具箱」两个问题上：模拟计算器、模拟购物车只校验函数名和参数；就算工具库很大，也得靠检索器缩水到几十个。两者都测不出真实世界里「在几百个真 API 里找路」的能力。
论文的做法很直接：把 65 个真实 MCP 服务器、552 个工具全部挂上，schema 合计超过 147k token，并且刻意不放检索器；三种模式（Oracle 只给最少工具、Standard 给 32 个 MCP、Max-Scale 全给）作为变量控制。
评分只看最终结果：文本答案由 LLM 裁判判定语义一致，文件改动由脚本校验状态；时效性问题用脚本实时抓 ground truth。
最反直觉的发现：工具变多时 9 个模型下降，但 Claude-4-Sonnet、Qwen3-235B-2507、GLM-4.5 在 Standard 模式超过 Oracle——它们会把被卡住的路径换成工具箱里的另一条路。
读完这节应明白：为什么「函数调用准确率」不等于「Agent 真的会干活」。
论文在引言里把现有基准的短板归为两类。
很多基准模拟计算器、简化版天气服务、假购物车，数据格式和交互方式跟生产系统差得很远。模型只要识别出表面套路就能拿分，而不是真的学会了规划与协调。
另一类虽然声称接入真实 API，但因为线上集成麻烦，并不真正执行，只校验「选中的工具名和参数对不对」，而不是交互的实际结果。
就算列出了大量 API，受上下文长度所限，设计者一次只能挂一小部分，常常靠检索模块每次挑几十个相关工具。
这保证了 prompt 不爆，但也绕开了「在庞大复杂的解空间里导航」这个能力本身。
这里的核心区分是：「能在给定 5 个工具里挑对的」和「能在 552 个工具里自己找到路」是两种能力。前者可以被检索器、迷你工具箱保护住，后者只有在真实规模和真实失败（认证错误、返回格式异常、路由被堵）下才会暴露。MCPVerse 想测的是后者。
MCP（Model Context Protocol）在 2024 年作为开放标准由 Anthropic 提出，统一了工具接入方式，工业界快速出现大量 MCP 服务器——这给了「挂几百个真实工具」一个工程前提。
这节看论文 Table 1 的横向对照：每个前作都缺了至少一列。
| 基准 | 标注方式 | 支持 MCP | 结果导向评分 | 实时 ground truth | 可执行工具（总 / 真实 / 模拟） | 单任务最大挂载工具数 |
|---|---|---|---|---|---|---|
| MCPVerse | 人工 | ✓ | ✓ | ✓ | 552 / 552 / 0 | 552 |
| BFCL-v3 | 人工 | ✗ | ✓ | ✗ | 76 / 0 / 76 | 37 |
| ToolBench | 合成 | ✗ | ✗ | ✗ | 0 / 0 / 0 | 17 |
| τ-bench | 合成 | ✗ | ✓ | ✗ | 28 / 0 / 28 | 15 |
| API-Bank | 人工 | ✗ | ✓ | ✗ | 73 / 0 / 73 | 8 |
| ToolSandBox | 人工 | ✗ | ✓ | ✗ | 34 / 0 / 34 | 34 |
| MCPBench | 人工 | ✓ | ✓ | ✗ | 27 / 27 / 0 | 10 |
| MCP-RADAR | 人工 | ✓ | ✓ | ✗ | 42 / 42 / 0 | 42 |
数据取自论文 Table 1。「真实」列是评估过程中可能被真正执行的工具数，「模拟」列是固定规则或模板返回的工具数。
可以读出三条：
MCPVerse 没有新式子，它的「方法」是三个互相咬合的设计决定。
从 Smithery、mcp.so、ModelScope 等平台收集，按三条标准筛选：鼓励长期稳定的服务；尽量少依赖 API key；可自动评估（Gmail、Notion 这类难以自动判定的，可以只放进池里当干扰项）。
论文同时提醒：工具数会随时间波动，提供方可增删工具。
类型为信息检索（地理、金融、学术、热点新闻）与系统操作（命令行、数据库、文件）；难度 L1 = 1–2 步单工具，L2 ≈ 5 步，L3 > 5 步、需多工具协作。
标注者（本科及以上）须保证：存在有效解、答案客观无歧义、贴合真实场景、不调工具解不出来。
不罚「偏离标准路径」。文本答案由 LLM 裁判判断语义等价；文件修改等状态变化由专用脚本校验（附录 D 给出 Q101 的脚本示例）。
E(·) 的两种实例化：
{"score": 1} 或 {"score": 0}（附录 D 的 prompt 原文）。alpha.txt（内容 Hello Alpha）和 beta.txt（内容 Hello Beta），任何一项不符返回 False。论文主实验用开源 QwQ-32B 做判定，附录 F 用 GPT-4o 复判：具体分数有差异（例如 Standard 模式 Claude-4-Sonnet 为 62.36 vs 61.26），但12 个模型的名次完全一致。这条是判断分数可信度的关键证据。
论文没有引入 ReAct、RolePlaying 之类复杂框架，理由是这些框架依赖大量 prompt 工程，会遮蔽模型自身能力。管线就是一个朴素的 agentic loop（见第 05 节），目标是测模型本身，而不是测某个框架。
同一个任务、同一套评分，唯一变化的是工具箱有多大——这就是「广阔动作空间是福是祸」的实验设计。
由标注者核实过的、解该题所需的最小工具集合。上下文长度随题而异。相当于传统评测的「喂到嘴边」。
所有题的 Oracle 最小集取并集，目标是适配主流模型 64k 上下文，留约 20k 给提问与回答。
在 Standard 基础上加入全部 MCP。论文报告只有 Claude-4-Sonnet 与 Gemini-2.5-Pro 能完整跑完——但 Table 2 显示 Gemini-2.5-Pro 在 Max-Scale 用的是提示词式函数调用（带 ∗），而且它的 31.4 恰好等于 GPT-4o 在 Max-Scale 列中残留的那个数字，疑似排版错位，见第 06 节脚注。
还有两个现实约束也必须写进设计：API 工具数上限（GPT-4o / GPT-5 为 128，Gemini 为 512）和上下文长度（DeepSeek-V3 仅 64k）。工具数超限但上下文够的模型，被迫改用「提示词式函数调用」：把整份工具 schema 塞进 system prompt，让模型以 JSON 列表形式输出调用（附录 E 给出模板，并特别叮嘱「不要伪造函数返回」）。
数据取自 Table 2；带 ∗ 的分数由提示词式函数调用取得；Max-Scale 的「—」表示受上下文限制无法评测，柱高按 0 绘制，只作占位。
论文 Figure 1 的结构，加上附录 B 的循环伪代码；记住「先接工具、再按模式挂载、最后裁判」这三步即可。
附录 B 给出的管线核心就是一个 while 循环，没有额外规划模块：
toolset = [connect_to(mcp).get_tools() for mcp in mcp_list]
history = [task]
while True:
resp = LLM(history, toolset); history.append(resp)
if not resp.tool_calls: return
for call in resp.tool_calls: history.append(call_tool(call))
这个设计意味着：MCPVerse 测的是模型在「工具一旦挂上去、上下文一旦满了」时的自主性，而不是某个 Agent 框架的工程技巧。
论文同样检验了「传统做法」：用 text-embedding-3-large 对模型自述的服务器需求做嵌入，余弦相似度取 top-5 服务器挂载。结果（Table 4）在四个模型上全部低于 Oracle 与 Standard——检索器在真实工具池上不够精确，反而比直接给全部工具更差。
下面整张 Table 2 原文转录；先看整体，再看那条反直觉的分界线。
| 模型 | 上下文 | 工具数上限 | Oracle | Standard | Max-Scale | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SR | L1 | L2 | L3 | SR | L1 | L2 | L3 | SR | L1 | L2 | L3 | |||
| DeepSeek-V3-0324 | 64k | 128 | 46.8 | 62.7 | 45.1 | 32.7 | 32.2 | 47.0 | 27.7 | 22.0 | — | — | — | — |
| DeepSeek-V3.1-Terminus | 128k | 128 | 56.6 | 64.4 | 57.3 | 48.3 | 52.1 | 62.0 | 49.4 | 45.0 | — | — | — | — |
| DeepSeek-R1-0528 | 64k | 128 | 56.4 | 70.5 | 56.4 | 42.4 | 49.9 | 65.1 | 47.4 | 37.3 | — | — | — | — |
| Claude-4-Sonnet | 200k | — | 62.3 | 71.6 | 62.7 | 52.5 | 62.4 | 75.9 | 60.4 | 50.9 | 44.2 | 45.8 | 40.5 | 46.2 |
| Qwen3-235B-A22B | 128k | — | 42.1 | 61.6 | 34.8 | 30.0 | 37.7 | 52.3 | 35.9 | 25.0 | — | — | — | — |
| Qwen3-235B-2507 | 1M | — | 44.8 | 62.5 | 44.8 | 27.1 | 53.2 | 63.9 | 51.8 | 43.9 | 31.6 | 44.3 | 23.7 | 26.7 |
| Qwen3-30B-A3B | 128k | — | 27.7 | 46.5 | 18.1 | 18.3 | 18.9 | 27.9 | 12.9 | 15.8 | — | — | — | — |
| Gemini-2.5-Pro | 1M | 512 | 48.7 | 66.3 | 42.6 | 37.3 | 45.3 | 62.4 | 41.9 | 31.6 | 31.4∗ | 37.7∗ | 35.7∗ | 20.8∗ |
| GPT-4o-20241120 | 128k | 128 | 42.1 | 59.1 | 40.2 | 27.1 | 31.4∗ | 37.7∗ | 35.7∗ | 20.8∗ | — | — | — | — |
| GPT-5 | 400k | 128 | 68.1 | 80.5 | 67.8 | 55.9 | 23.4∗ | 30.6∗ | 19.7∗ | 20.0∗ | — | — | — | — |
| Kimi-K2-0711 | 128k | 128 | 59.4 | 70.9 | 59.8 | 47.5 | 16.3∗ | 24.4∗ | 24.4∗ | 0.0∗ | — | — | — | — |
| GLM-4.5 | 128k | — | 55.0 | 70.9 | 58.5 | 35.6 | 59.1 | 67.4 | 60.7 | 49.2 | — | — | — | — |
※ 转录说明：原论文 Table 2 中 Gemini-2.5-Pro 的 Max-Scale 一行印在 GPT-4o 行的标题处，且数字 31.4 / 37.7 / 35.7 / 20.8 与 GPT-4o 的 Standard 列完全相同。结合正文「只有 Claude-4-Sonnet 和 Gemini-2.5-Pro 能完成 Max-Scale」以及「Gemini 的 Max-Scale 分数由提示词式函数调用获得」，此处按 Gemini 行理解；标 ∗ 者为提示词式函数调用，Max-Scale 的「—」为上下文不足无法评测。
从 Oracle 到 Standard，Claude-4-Sonnet（+4.1）、GLM-4.5（+4.1）、Qwen3-235B-2507（+8.4）上升；其余全部下降。论文按下降幅度把后九者分成三类：
同一个任务，Claude-4-Sonnet 在 Oracle 模式按标注路线调用 dataviewer 的 validate 与 filter，但把 auth_token 从布尔值错填成字符串，触发鉴权错误后放弃。
在 Standard 模式，它遇到同样的初始失败后，转而调用工具池里的 fetch 绕过被堵的路，完成任务。论文称之为 emergent solution path / “hacking” behavior：模型不是学会了某条标准路线，而是学会了在被堵时换路。
论文自己的数据与设计里，至少能读出五条限制。
552 个工具是真实在线 MCP，提供方可随时增删工具（论文自己说明「这个数会波动」）；线上答案也会改变。时效性问题虽用脚本抓实时 ground truth，但依赖外部网络的服务一旦下线，任务就不可复现。
GPT-4o、GPT-5、Kimi-K2-0711 的 Standard 分数是通过 提示词式函数调用得来的。Table 3 显示：在同一个 Claude-4-Sonnet 上，同一套 prompt 就能让分数砍半。因此它们的断崖式下降与模型能力有多少因果关系，论文没有做完整的解耦；作者自己措辞是 “likely accounts for”。
文本类答案由 QwQ-32B 判语义一致性。附录 F 用 GPT-4o 复判，12 个模型的名次完全一致，说明排名方向稳定；但分数并非「客观真值」，裁判本身也没有逐题人工核验。
论文不跑 ReAct 等框架，理由是测「模型本身」。这意味着 MCPVerse 分数衡量的是裸模型 + 简单循环，不反映带规划、记忆、多 Agent 组装的真实产品表现。
Max-Scale 只有 3 个模型有可读分数（其中 Gemini 为 ∗），其余全是「—」。Max-Scale 的排名与结论证据量远小于 Standard。
一句话：MCPVerse 最有说服力的不是绝对分，而是「Oracle → Standard」的增减号——它在多大工具集里还能稳定选择与换路，这个方向性结论比任何单个百分数都更稳。