只有 48.8% 的工具服务器能起来：MCP-Atlas 把“工具调用可靠性”推到了路由层

引子：今天没有新模型，只有一份难看的分数

9 月 15 日没有旗舰模型发布。真正该先看的，是两件叠在一起的事：Scale AI 把 MCP-Atlas 开放成可复现的工具调用基准；同一天，一份独立研究从 MCP Registry 里随机抽了 400 个服务器，挨个启动一次，不做任何修复。195 个起来了。

一半多一点。而如果只测作者手工挑的那 24 个，这个数字会跳到 66.7%。

过去两年我们把两件事混着谈：模型够不够聪明，工具够不够可用。今天它们被拆开了，而且第二件事比大多数人估计的糟得多。

一、MCP-Atlas 测的是“发现”，不是“调用”

MCP-Atlas 的构造方式值得拆开看：36 个真实 MCP 服务器、220 个工具、1,000 个专家手写的自然语言任务，每个任务需要 3 到 6 次工具调用，而且要跨服务器编排。1,000 个任务里 500 个公开，另外 500 个握在手里保护排行榜。

设计上最狠的一点是：提示词里不出现服务器名、不出现工具名，也不给参数。你得从一句业务需求里推断出该用哪些工具，而任务集里还刻意塞了语义相近的干扰项。这把“调用”和“发现”分开了。给模型一份精选好的四工具清单让它挑一个，那是在测调用；给它一个真实注册表，里面有四个工具看着都像对的，正确答案却要按顺序用上其中三个、跨两个服务器——那才是在测发现与编排。生产里崩掉的，从来是后者。

分数口径这件事必须讲清楚。Scale 在 2025 年 9 月首发的排行榜用的是二元终答匹配：GPT-5 以 44.5% 领先，中位数模型 Kimi-K2 只有 23.9%，一半的模型挤在 8% 到 38.3% 之间。后来那篇论文（2026 年 1 月首投，5 月修到 v3）改成按 claim 覆盖率评分，20 个前沿模型在 0.75 覆盖率阈值下最高能到 82.2%。

44.5% 和 82.2% 不矛盾，也不是模型突然变强了，它们问的不是同一件事：一个问“最终答案对不对”，一个问“有没有答出从工具输出里抽出的 75% 的原子事实”。所以看到发布稿引一个 MCP-Atlas 数字，第一句该问：哪个口径、哪个任务集、阈值多少。

二、更硬的一层：注册表里一半的工具是“死的”

上面那项抽样研究的数字更不留情面。附一张表：

抽样框是注册表里“发布到 npm、声明 stdio、状态 active”的 7,258 个服务器，来自 2026 年 8 月 22 日普查到的 24,135 个。固定随机种子，每个服务器只启一次：没有重试、没有修包、没有补凭证。

两个细节比 48.8% 这个数字本身更值得记：

一是“从未启动”远多于“缺凭证”。 150 比 53，差不多三倍。真凶不是权限配置，是包本身就起不来。“我配好 key 就能用”这个假设，在这批数据面前站不住。

二是精挑细选只买到 17.9 个百分点。 手工挑的 24 个样本里 16 个能跑，66.7%。这 17.9 个点就是“人工 curated”的全部溢价：精心维护的工具清单看起来比真实长尾好得多，而这种筛选恰好把失败藏了起来。你本地跑得通，不代表线上那批服务器跑得通。

握手成功的 195 个服务器挂出 2,766 个工具，JSON Schema 致命违规是零——格式比想象中规矩。但 58.8% 的工具没打任何安全标注：readOnlyHint、destructiveHint、idempotentHint、openWorldHint 四个全空。一个不说明“这个操作会删数据”的工具清单，路由层没法替你做安全决策。

还有个关于“工具数量”的坑：真实部署的工具描述里，“名字加描述逐字重复”的只占 0.4%（10/2,766），而 BFCL v4 的发布文件里是 68.8%，UltraTool EN 是 85.6%。作者写明了这不能读成“基准造假”——问题在计数程序：不去重就聚合，你数的是“任务重复次数”，不是“工具数量”。

三、价格既不是能力的代理，也不是可靠性的代理

把公开榜单和实时价格叠在一起看，这条最扎眼：

（快照日期 2026-09-15，榜单中 38 个模型有公开分数。）

三个读法：

顶端几个点要付 90 倍。 Claude Fable 5 拿到 83.3%、花 90.9×；Hy3 拿到 79.1%、花 1×。差额 4.2 个百分点，代价 90 倍。对绝大多数内部 Agent，这 4.2 个点买不到对应的业务价值，换一档就能把预算释放到别处。

便宜不等于可靠，这是最容易踩的。 Nova 2 Lite 是 Hy3 的 4.2 倍价钱，分数只有人家的三分之一，24.6% 意味着四次任务里三次工具链走不通。如果只按“便宜就上”，你很可能正好挑中它。

最贵的也没有最可靠。 GPT-5.2 Pro 要价 189 美元，分数 77.8%，排在 Hy3 后面。价格反映训练成本和品牌定位，不是工具调用的稳定性。

结论很直接：选模型要按“实测的工具调用通过率”分档，而不是按单价或参数规模。前提是，你的备选集得足够宽。

四、路由层必须改的三件事

第一，把工具的“存活”当作可观测指标。 别等模型报错才知道工具挂了。定期对每个 MCP 服务器做握手探测，把 48.8% 那个概率挡在应用之外：起不来的直接摘出可用池，别让模型去猜为什么调用失败。

第二，日志要记实际执行的模型名和工具调用次数。 一次任务走了 3 步还是 6 步，直接决定成本。工具调用次数是成本的一等变量，比 token 单价更能解释账单。

第三，重试预算要显式写进编排。 工具链本身有长尾抖动，任何“一次调用成功”的假设都是乐观的。给每个任务留出纠错额度，并在达到上限时降级到下一档模型，而不是一直重试同一档。

import os
from openai import OpenAI

client = OpenAI(
base_url="https://router.accels.tech/v1",
api_key=os.environ["ACCELS_API_KEY"],
)

# 1. 先摸清备选集有多宽——按可靠性选路的前提是型号够多
roster = [m.id for m in client.models.list()]
assert {"hy3", "seed-2-1-pro", "claude-opus-5"} <= set(roster)

# 2. 按实测的工具调用通过率分档，而不是按单价或参数规模
TIER = {
"hy3": 0.791, # 单服务器、少步数任务够用
"seed-2-1-pro": 0.838, # 默认档
"claude-opus-5": 0.858, # 跨服务器多步编排
}

def pick(steps: int) -> str:
floor = 0.85 if steps >= 4 else 0.78
ok = [(m, s) for m, s in TIER.items() if s >= floor]
if not ok:
raise RuntimeError("没有型号满足该任务的工具调用成功率下限")
return min(ok, key=lambda kv: kv[1])[0] # 达标里挑最便宜的

# 3. 把失败当常态：重试与降级写在调用里，不写在祈祷里
def call_with_tools(prompt: str, tools: list, steps: int) -> str:
model = pick(steps)
messages = [{"role": "user", "content": prompt}]
for _ in range(steps + 2): # 预留两次纠错额度
resp = client.chat.completions.create(
model=model, messages=messages, tools=tools, tool_choice="auto",
)
msg = resp.choices[0].message
if not msg.tool_calls:
return msg.content or ""
messages.append(msg)
for tc in msg.tool_calls:
messages.append({
"role": "tool",
"tool_call_id": tc.id,
"content": dispatch(tc.function.name, tc.function.arguments),
})
return ""

落地：一个统一的模型入口让上面三件事变得可行

这三件事单独做都不难，难在它们要求你同时握住三样东西：足够宽的型号池、稳定的调用通道、能对齐的账单。

型号池不够宽，第一件事就做不成。能达标的档位分散在至少四家厂商之间：Hy3 在 0.66 美元的价位拿到 79.1%，Seed 2.1 Pro 用 5.34 美元拿到 83.8%，Claude Opus 5 用 30 美元换到顶部那 2 个点。只在单一厂商内部选，等于把“性价比”直接砍掉。

调用通道不稳，第二件事就全是噪声。MCP 生态的长尾只有一半是活的；如果连模型入口本身都在抖动，你分不清失败是模型选错了工具，还是链路断了。统一入口的价值在于把这一层固定下来：一次接入、长期可用，不必为每个厂商单独维护鉴权、重试和限流。

账单不能对齐，第三件事就永远算不清。跨服务器多步任务的真实成本是“调用次数 × 每步上下文体量 × 该型号单价”，三个因子散在不同厂商的账单里，归因无从谈起。统一计费把这个乘法收敛到一张表上，你才可能发现“换个便宜档位成本砍半、成功率仍有 96%”这种结论。

router.accels.tech 就是照这个思路做的：Accels 是一家新加坡的公司，接口是标准 OpenAI 兼容格式，base_url 换成 https://router.accels.tech/v1 就能用，模型池覆盖主流厂商的完整档位，单一密钥、单一账单。上面代码里的 client.models.list() 能列出你可用的全部型号——按可靠性分档选路，第一步就是把备选集铺开。

结语

今天这份数据的意义不在于“某家模型又赢了几个点”。它把一件长期被含糊处理的事抬到了台面上：工具调用可靠性是一个可以测量、可以排序、可以在路由层决策的工程指标，它和推理能力不是一回事，和价格更不是一回事。

下次有人拿一个 MCP-Atlas 分数来对比模型，问清口径；下次要上多步 Agent，先数清一次任务到底要几次工具调用。把这两件事做扎实，比追一个新发布的模型有用得多。

来源

• MCP-Atlas 论文（Scale Labs）：https://labs.scale.com/papers

• MCP-Atlas 排行榜与实时价格快照（2026-09-15）：https://anotheraiwrapper.com/tools/llm-pricing/evals/mcp-atlas

• MCP-Atlas 两个分数口径的拆解：https://ai-agent-engineering.org/news/mcp-atlas-says-445-and-822-ask-which-number

• MCP Registry 随机抽样探测报告（arXiv:2609.10962v1）：https://blog.pebblous.ai/report/mcp-registry-random-sample-probe/en

• AI Daily 2026-09-15：https://quidproquo.cc/posts/daily/2026-09-15-ai-agent-daily-en

• AGI HUNT 日报 2026-09-15：https://agihunt.info/en/daily/2026-09-15

• DataLearnerAI MCP-Atlas 榜单：https://www.datalearner.com/benchmarks/mcp-atlas