MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers

1 · 背景:为什么 MCP-Atlas 是第一个被 frontier 官方采用的 MCP benchmark

1.1 一个被低估的事实

2025 下半年到 2026 上半年,围绕 Model Context Protocol (MCP) 的 benchmark 至少有 6 篇 paper / repo:MCP-Universe (231 task / 11 server)、MCPEval (676 task, auto-gen)、MCP-Bench (104 task, Accenture)、Toolathlon (108 task / 32 app, HKUST-NLP)、MCPMark (127 task / 5 server, eval-sys)、LiveMCPBench (95 task / 70 server, mostly mock),还有这篇 MCP-Atlas (1000 task / 36 server, Scale AI)。它们的方法学差异其实并不悬殊 —— 都是"多 server 跨 tool 编排 + 某种自动化 verifier"。

但到 2026 年 4 月 Anthropic 发布的 Claude Opus 4.7 system card 里,作为 "agentic tool use" 一档的代表性 benchmark 出现的只有 MCP-Atlas 一个,数字是 77.3%。同一张表里 MCPMark / Toolathlon / MCP-Bench 都没出现。这是一件值得追问的事情 —— 因为它直接决定了未来 6-12 个月哪个 benchmark 会被 community 当作"标准刻度"来衡量 agent 能力。

1.2 这篇笔记和之前 MCP benchmark 笔记的关系

之前用户已经精读过的 MCP benchmark 系列:

这就是 §8 要回答的核心问题:规模上 Atlas ≈ Toolathlon-Gym × 2,验证设计上没有压倒性的新意 —— 那么 frontier lab 选它的真正原因在哪儿? 我的答案在 §8。

2 · 设计哲学:36 / 220 / 1,000 的规模为什么"刚好够"

2.1 三件事的 trade-off 几何

所有 MCP benchmark 都在 3 个轴上权衡:

2.2 "为什么 36 而不是 5 或 70"

选择 36 个 server 而非 5 个 (MCPMark) 或 70 个 (LiveMCPBench) 的理由,paper 没有展开论证,但能从数据反推:

36 这个数字的含义是: 每 bucket 5-7 个,既覆盖到了"工具组合性"(产生 cross-server task),又把每个 server 的 API key 管理 / 速率限制 / 数据初始化复杂度控制在 docker compose 能处理的级别。70 个 (LiveMCPBench) 的代价是必须 mock,5 个 (MCPMark) 的代价是没法构造跨域 task。

2.3 "为什么 1,000 task 不 over-fit"

1,000 task 的"够用感"来自两件事:

1. 500 公开 + 500 hold-out: 这是 paper 明文写的反污染设计。MCPMark / Toolathlon 都没有 hold-out, 全部 task 都进了 HuggingFace,因此 long-term 上 train-on-eval 风险更高。Atlas 的 500 hold-out 由 Scale Labs 内部跑 → 这意味着 frontier lab 拿到的 leaderboard 分数会比自跑高 ~3%(因为公开 500 容易被 RL 训过)。
2. CI 宽度: 在 leaderboard 上每条记录都标了 ±2.5 ~ ±3.1 的 95% CI —— 这正是 ≈500 个 binary task 的 1/(2√n) 的理论下限。换言之,Atlas 的设计假设是每相邻 2-3% 是一档显著差异。100-task 量级的 benchmark 给不了这个分辨率。

3 · 任务构造方法 — 怎么搞出 1,000 个 verifiable task

3.1 三层人工 + 一层 LLM 的 pipeline

这是 paper 里写得最朴素也最关键的部分: 1,000 个 task 是真的人写的,不是 LLM 生成的(对照 MCPEval 676 auto-gen)。流程:

3.2 task 的几个关键约束

• 3-6 tool call 是目标长度;大多数 task 跨 ≥ 2 个 server;~1/3 含 conditional logic(下一步 tool 取决于上一步输出)。
• single-turn prompt: agent 收到的是一次性 user message,不允许 user back-and-forth 反复确认。这是和 Toolathlon (multi-turn) 的一个显著区别 —— Atlas 故意排除 dialog 能力,专注于 planning + execution。
• distractor tool: 每个 task exposed 10-25 个 tool,但其中只 3-7 个是真正解题需要的。这逼着 agent 自己做 tool selection,不是只 dispatch。

3.3 HF dataset schema

{
  "TASK": "uuid-style-24char-id",
  "ENABLED_TOOLS": "tool1, tool2, ... (183-1.44k chars)",
  "PROMPT": "自然语言 user 请求 (84-601 chars)",
  "GTFA_CLAIMS": "claim_1; claim_2; ... (79-3.02k chars)",
  "TRAJECTORY": "完整 ground truth tool-call 序列 (2k-4.4M chars)"
}

TRAJECTORY 字段是个亮点 —— 它把人写的 reference trajectory 也开源了。这点 MCPMark 和 Toolathlon 都没做(只给 verifier 不给 reference traj)。对 SFT / behavior cloning 训练而言,这是个非平凡的资源。

4 · 评测 pipeline:harness + claims rubric + judge

4.1 三段式 pipeline

1) Completion phase
   uv run python mcp_completion_script.py \
       --model claude-opus-4-7 \
       --input tasks_500.jsonl \
       --output traj_opus47.jsonl
   ↓ 调用 localhost:1984 (MCP server 集群) + localhost:3000 (completion svc)
   ↓ agent 单轮 plan, 多次 tool call 直到吐出 final answer

2) Scoring phase
   uv run mcp_evals_scores.py \
       --input-file traj_opus47.jsonl \
       --model-label opus47
   ↓ 拿 Gemini 2.5 Pro 当 judge
   ↓ 对每个 claim 打 {fulfilled=1, partially=0.5, not_fulfilled=0}
   ↓ coverage = Σ claim_score / |claims|

3) Pass/fail
   pass if coverage ≥ 0.75 else fail
   pass_rate = #pass / #tasks

4.2 关键设计决策

4.3 失败模式分析(诊断的真正贡献)

paper §6 / appendix 给了一张 frontier model 失败原因占比表,这是它比 MCPMark / Toolathlon 更有 "model-card 友好度"的关键 —— Anthropic / OpenAI 可以拿这张表直接讨论"我的模型短板在哪一档":

注意"no tools called"在所有模型上都占主导 —— 包括 frontier model。这说明"决定调用 tool"本身就是个非 trivial 决策,模型在不确定时倾向于直接幻觉答案。

5 · 🔍 开源现状 — repo 实地清点 (CRITICAL)

这一节是用户最关心的。把 github + huggingface + paper 三处对照后,清单如下:

5.1 self-host 跑通 500 task 需要什么

依赖: Docker, UV (python pkg manager), jq, Python 3.10+
.env 里两个 key: LLM_API_KEY (待测模型), EVAL_LLM_API_KEY (Gemini 2.5 Pro judge)
端口: 1984 (MCP servers 容器), 3000 (completion svc)

额外需要的 API key (运行全 500 task 时):
- brave_search, exa, oxylabs, twelvedata, alchemy, ...
- 部分 server (notion / slack / airtable / gcal / mongo) 需要 OAuth + 恢复 fixture

跑通 10 个 sample task 的 minimum 路径不需要付费 key — 这一点比 MCPMark 友好(MCPMark 的 5 个 server 几乎都要 paid key)。

5.2 与同期 benchmark 的开源度对比

6 · 实验结果 + 当前 leaderboard 全表

6.1 paper v2 (2026-05-04) 报告的分数

paper 自己的话: "Top frontier models achieve pass rates exceeding 50%, with primary failure modes related to inadequate tool usage and task comprehension."

6.2 Live leaderboard (Scale Labs, 截至 2026-04-08)

6.3 几个有意思的观察

• Muse Spark 82.2% 是 Scale AI 自家模型(2026 年新发) —— 第 1 位是自家这件事本身值得 raised eyebrow,但 Scale 在 leaderboard 做 ground truth 同时上自家模型 SOTA 是 RM benchmark 时代就有的传统(详见 LMArena ↔ Scale 关系)。
• Gemini 2.5 Pro 在 paper 里只跑出 8.8% —— 但它本身就是 judge 模型!这意味着 Atlas 的 judge 模型解题能力远低于它当 judge 的能力,这在心理学叫 evaluator-solver gap,是 LLM-as-judge 范式的常见现象。
• Claude vs GPT 的 head-to-head: 几乎每一代 Claude 在 Atlas 上都领先同代 GPT 一个身位 (Opus 4.7 79.1 vs GPT-5.5 75.3, Opus 4.5 69.8 vs GPT-5.2 67.6)。这强化了 Anthropic 的 "agentic" 叙事 — 也部分回答了为什么 Anthropic 选这个 benchmark 上 model card。

7 · 与 MCPMark / Toolathlon / MCP-Bench 的并排对比

关键差异化(按重要性排序):

1. Live leaderboard + hold-out — 唯一一个有"非数据集化"承诺的
2. 规模 10× — 让 CI ≤ 3%,是 frontier 模型间分辨可行的最低要求
3. reference trajectory 也开源 — 给后续 SFT 喂料
4. Scale AI 的销售/数据网络 — 不在 paper 内,但是隐含 distribution advantage

8 · 为什么这篇被 frontier 采用 — 我的假设

把所有证据放在一起,我对 "为什么 Anthropic 把 MCP-Atlas 而不是 MCPMark / Toolathlon / MCP-Bench 写进 Claude Opus 4.7 model card" 的最佳猜测,按可信度排序:

H1 (最强): leaderboard infra + hold-out 让数字 "可被定期更新"

Anthropic / OpenAI / Google 在写 model card 时需要的不是一个静态 paper 数字,而是一个未来发新模型时能继续 quote 的 benchmark。MCPMark / Toolathlon 都是"paper-and-go"模式 — 一旦 paper 发了,数据集 freeze 在 HuggingFace 上,leaderboard 就要靠社区 cobble 起来,容易污染。Atlas 的 Scale Labs leaderboard 是第一个 by-design 持续运营的 MCP benchmark。这对 frontier lab 来说是基础设施 lock-in。

H2 (次强): Scale AI 与 Anthropic 的长期 data 合作关系

Scale AI 是 Anthropic 最主要的 RLHF data partner 之一(以及 OpenAI 的)。当 Scale 推出一个 benchmark 时,商务通道上 Anthropic 团队拿到这个 benchmark 的时间会早于其他 academic 团队 — 一个 frontier lab 内部已经用了几个月的 benchmark,自然会出现在 model card 里。MCPMark/Toolathlon 是学术 / 创业团队,没有这条快车道。这是个 "Scale AI 卖通道" 的故事,不是技术故事。

H3 (中等): 规模够大让 CI 够窄

1000 task → 500 公开测试上 95% CI ≈ ±2.5%。Anthropic 报 Opus 4.7 = 77.3% 时 vs Opus 4.6 = 75.8%,这 1.5% 在 100-task benchmark 上根本不显著 (±5% CI),在 500-task 上才勉强 statistical claim。Model card 写代际 incremental improvement,必须有低 CI benchmark。

H4 (弱): claims-based rubric 的可解释性

Atlas 的 claims rubric 给了 fine-grained 失败诊断("no tool called" 占 36%, "incorrect parameter" 占 14% 这种)。这种 breakdown 是 model card 写"我们改进了 X 的能力"时需要的素材。MCPMark 的 binary pass/fail 给不了这种叙事。

H5 (诚实承认): Claude 在 Atlas 上分数最好看

从 leaderboard 看,Claude 系列在 Atlas 上的相对排名比在 SWE-bench / τ-bench 上更靠前(Opus 4.7 第 2,只输给 Scale 自家)。不能排除 "Anthropic 选这个 benchmark 因为这个 benchmark 上他们赢得最漂亮"。这是 model card benchmark 选择的公开秘密。

9 · 局限 / 个人 take

9.1 论文方法学的真实局限

• Single-turn 是个 strong assumption: 真实 agent 用户经常 mid-task 改主意 / 加约束。Atlas 完全不测这个。Toolathlon 在这一点上反而更接近现实。
• Judge = Gemini 2.5 Pro 是个 weak 模型(它自己在 Atlas 上只考 8.8%)。让一个解题能力低的模型去 judge frontier 模型,长期有 ceiling 问题。Scale 自己也承认 "judge has been updated, scores revised" — 说明 judge 是个 moving target,跨 snapshot 比较得小心。
• 没有 RL 训练 fork: Atlas 还没有出现像 Toolathlon → Toolathlon-Gym 那样的 RL 训练版,这意味着开源社区目前不能直接用 Atlas 训 agent。考虑到 reference trajectory 已经开放,这个 fork 出现是迟早的事。
• API key 配齐的实际成本: 跑完 500 task 需要 ≥ 10 个 paid API (oxylabs / twelvedata / alchemy / brave / exa / ...),自托管 cost ≥ 数百美元/次。这对独立研究者是 entry barrier,只有大组能 reproduce。

9.2 我的判断

MCP-Atlas 不是技术上最聪明的 MCP benchmark — 它是产品化做得最好的那个。Scale AI 把它当一个持续运营的 leaderboard product(类似 LMSys Chatbot Arena 的位置),而不是单次发布的 paper artifact。这就是它和 MCPMark / Toolathlon 的根本差别,也是 frontier lab 需要的差别。

对用户(szhang967)的实际建议:

9.3 一个 counterintuitive finding

看 §6.3 的失败模式表,"no tools called" 占了 frontier model 36% 的失败原因 —— 即第一档 failure mode 不是 "tool 用错",而是 "完全不调用 tool"。这与"模型越强越倾向于直接幻觉答案而不 ground"这个老观察对上了。对 prompt engineer 的 actionable insight:在系统提示里强制要求 "for any factual question, you must call at least one tool" 可能直接消除 1/3 的 failure。这是从 Atlas 中提炼出的最有用的工程经验,paper 没有显式 highlight 但数据明摆着。