MCP服务工具数实测：5到100个，准确率不降反增

为什么大家都在劝你少写工具

关于 MCP 服务器设计，最流行的建议是"工具越少越好"。一位开发者为此读完了 91 份资料——21 份官方文档、28 篇厂商博客、20 篇独立博客、2 个论坛帖子和 20 篇论文——全部通读。结果是：38 份资料建议精简工具，22 份建议通过搜索或延迟加载控制可见工具集，8 份推荐 code mode（用一两个工具跑代码），没有一份主张把所有工具都暴露出来。

20 份资料给出了具体数字：Workato 说 5-8 个，Phil Schmid 说 5-15 个，OpenAI 说每个命名空间下不超过 10 个、总数不超过 20 个，Gemini 和 Speakeasy 说 10-20 个，Claude 文档说 30-50 个，Archestra 甚至给出了"40 是拐点"的说法。但这 20 个数字里只有 3 个来自作者自己的测量。

两个被反复引用的说法站不住脚："模型在 30 个工具时崩溃"可以追溯到 RAG-MCP 论文，而该论文统计的是提示词中的 MCP 服务器数量，不是工具数量；"Cursor 不会接受超过 40 个工具"在 2026 年 1 月上限被移除后就不再成立。91 份资料中，46 份是主观意见，8 份转引他人，37 份做了某种测量，但只有 10 份真正测量了工具数量与准确率的关系——7 篇论文、GitHub Copilot（从 40 个减到 13 个工具，准确率提升 2-5 个百分点）、LangChain，以及一个在 1.7B 小模型上的非正式测试。

这就是问题所在：所有人都这么说，但几乎没人亲自测过。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的协议，用于让 AI 应用以统一方式连接外部工具、数据源和提示模板。在 MCP 的架构中，一个 MCP 服务器 会向客户端（如 Claude Code、Cursor、Codex CLI）暴露一组「工具」，每个工具由名称、描述和 JSON Schema 定义的参数组成。客户端在发起对话时，会把这批工具的元数据以某种形式塞进模型的上下文窗口，模型据此决定是否调用、调用哪一个、传什么参数。因此「工具越多，提示词越长、模型越容易选错」成为直觉上的担忧，也催生了「工具越少越好」的经验法则。但工具清单的注入方式并非只有一种：有的客户端把全部 schema 一次性写进系统提示，有的只注入名称、让模型按需检索 schema，还有的完全不让 schema 进入提示词、改由模型写代码去查询。理解这些差异，是理解本文成本与准确率结论的前提。

实测方法：1932 次运行，三个客户端

这位开发者构建了一个假服务器，包含 100 个逼真的文件与文档工具，名称和 schema 都写得像真的一样。其中有一部分是故意设计得容易混淆的，比如 pdf_compress、pdf_optimize 和 image_compress。服务器还有一个分组变体——7 个工具覆盖 50 个操作，以及一个模糊命名变体。所有工具都不真正触碰文件，服务器的调用日志就是评判标准。

测试任务是 18 个有已知答案的任务，其中 10 个是模糊任务。工具数量从 5 到 100（取 5、10、20、30、40、50、75、100），每个条件跑两次，共 1932 次运行。三个客户端分别是：Claude Code（Opus 5.5，工具搜索开和关两种模式）、Codex CLI（GPT-6.1-sol）和 Antigravity（Gemini 3.1 Pro），各自使用自己的订阅。所有测量数据、结果 CSV 和每次运行的原始日志都公开在 GitHub 上。

这个方法论的关键点：服务器不执行任何真实操作，所以"正确性"完全由模型是否调用了正确的工具来判定，排除了执行结果带来的噪声。

ToolSearch 指客户端提供的一种按需加载工具 schema 的机制。当工具数量很多时，若把每个工具的完整 JSON Schema 都塞进提示词，会迅速消耗上下文并推高成本。ToolSearch 的做法是：提示词中只列出工具名称（有时附一句极简说明），模型判断需要某个工具后，先调用一次特殊的搜索/加载工具，把目标工具的 schema 拉进上下文，再发起真正的工具调用。本文中 Claude Code 默认开启该模式，因此每次运行都恰好出现一次 ToolSearch 调用，且模型仅凭名称就能在近似名称之间完成选择。这一机制是「搜索开」与「搜索关」两条成本曲线分叉的根本原因，也解释了为什么开启搜索在工具数较少时反而更贵——多出的那次调用本身有开销。

核心发现：准确率不随工具数下降

结论出乎意料：所有使用独立工具的运行，从 5 个工具到 100 个工具，在三个客户端中、在 Claude Code 的两种模式下，全部完全正确。包括每一个模糊任务，也包括在 75-100 工具时加入的 50 个额外混淆工具。

在 Opus 5.5、GPT-6.1-sol 和 Gemini 3.1 Pro 上，"工具越少越准确"在 5 到 100 这个区间内没有出现。这与调查中的一个警告一致：性能退化程度高度依赖具体模型。换句话说，那些"XX 个工具就崩溃"的说法，很可能来自更老、更小的模型，或者根本就是没有测过。

Claude Code 的工具搜索从未隐藏正确的工具。每次运行都恰好做一次 ToolSearch 调用，作为第一个动作，然后按精确名称选择工具。模型在读取任何 schema 之前，仅凭工具名称就能在近似名称之间做出选择。

真正的成本：不同客户端差距巨大

准确率不变，但成本变化很大。而成本取决于客户端如何加载工具，不取决于模型本身。以下是每个客户端在不同工具数量下的输入 token 消耗（每次运行平均值，36 次运行，全部完全正确，所以表格只反映成本）：

客户端	工具如何到达模型	首次调用：5/50/100 工具	每次运行
Claude Code，搜索开（默认）	仅名称，schema 按需通过 ToolSearch 加载	3.9k / 4.6k / 5.4k	13.8k / 17.4k / 19.9k
Claude Code，搜索关	所有 schema 全量注入提示词	4.1k / 11.7k / 20.2k	9.3k / 27.9k / 48.6k
Codex CLI	Code mode：schema 不进入提示词，模型用代码搜索	13.2k 恒定	45.3k / 61.4k / 78.2k
Antigravity（Gemini 3.1 Pro）	仅名称，schema 文件按需打开	3.8k / 4.1k / 4.3k	15.7k / 20.5k / 18.6k

Claude Code 中，工具搜索是最关键的开关。它默认开启：只有工具名称进入提示词，模型通过一次 ToolSearch 调用加载所需的 schema。这个额外调用让它在约 19 个工具以下比全量加载更贵，在 19 个以上更便宜——在 100 个工具时每次运行少用 59% 的输入 token。

但更少的 token 不等于更便宜。按列表价计算，在 100 个工具时，开启搜索的每次运行花费 $0.047，关闭搜索为 $0.038。原因是缓存输入很便宜，而搜索增加了一次额外调用。搜索节省的是上下文空间，不是钱。

一个值得警惕的细节：作者在实验初期因为一个隔离标志意外关闭了 Claude Code 的工具搜索，导致第一次报告的"搜索关闭"数据其实是错误标注的。仅仅一个标志就让首次调用成本差了 4 倍。

Code mode 是另一种控制工具可见性的思路：不让工具 schema 进入提示词，而是给模型一两个「写代码/执行代码」的通用工具，由模型编写代码去枚举、检索并调用底层工具。这样提示词体积几乎与工具总数无关，代价是模型需要多轮代码交互才能完成一次调用。本文中 Codex CLI 采用这一模式，首次调用稳定在 13.2k token，但每次运行的总输入随工具数上升而显著增长（45.3k 到 78.2k）。需要注意的是，缓存输入（cached input） 的价格通常远低于未缓存输入，因此「输入 token 更少」并不自动等于「账单更便宜」——这正是 Claude Code 开启搜索时 token 省 59%、按列表价反而更贵的原因。

分组策略：对一个客户端有利，对另一个有害

把所有 schema 全量加载时（Claude Code 搜索关闭），7 个分组工具的成本相当于 14 个独立工具，准确率 100%。但在 Claude Code 默认的搜索开启模式下，分组几乎无关紧要：每次运行 16.1k 输入 token，而 50 个独立工具是 17.4k。分组只在 schema 全量注入的场景下有明显收益。

Antigravity 是整个实验中唯一准确率下降的地方，降到 89%。Gemini 跳过了多操作工具的 schema 读取，猜测操作名如 delete、help、fake_op，并错误执行了 3 次。这说明分组工具对某些客户端反而增加了风险——模型需要先读 schema 才能知道有哪些操作，而它可能不读就猜。

模糊命名的影响：取决于客户端

在模糊命名变体中，开发者保留了同样的 100 个工具和同样的描述，只是给工具起了随意的名字：optimize_file、optimize_document、process_image、combine_files、handle_pages。

准确率保持不变：276 次运行全部正确，没有错误工具被执行。描述决定了答案。

但在模型先看到名称的场景中，名称决定了通往答案的路径。在 Claude Code 搜索开启模式下，诚实的名称让模型在 72 次运行中有 69 次精确加载了所需的 schema；模糊名称下只有 7 次。模型退回到关键词搜索，100 个工具时每次运行加载的 schema 从 1.6 个涨到 7.6 个（有一次加载了 23 个），输入增长 21%。Gemini 在 72 次运行中有 34 次先打开了错误工具的 schema，10 次用空参数探测错误工具。在真实服务器上，如果某个工具没有必需参数，这些空调用就会执行。Gemini 在 100 个工具时输入增长 38%。

最容易误导的名称包括："3 JPGs into one PDF" 导向了 combine_files（实际合并 PDF），"shrink a PNG" 导向了 optimize_image，pptx 和 docx 转 PDF 在 convert_file 和 convert_document 之间混淆。

命名规范与 64 字符预算

所有客户端都能调用的名称只能包含字母、数字、下划线和连字符，最多 64 个字符。Claude API 拒绝包含点号的名称，某些客户端会在自己这边重命名点号。这 64 个字符是共享的：Claude Code 调用你的工具时会用 mcp__<server>__<tool> 的格式，所以服务器名称太长会吃掉工具名的预算。

还有一个意外发现：Gemini 的 API 在一次急切加载运行中拒绝了包含整数枚举的工具 schema。

工具名中的点号问题 值得单独说明。MCP 生态中不少工具名习惯写成 namespace.action 的形式（如 files.convert），但 Claude API 会直接拒绝包含点号的工具名，部分客户端则会在本地把点号替换成下划线或连字符后再转发。这意味着同一个服务器在不同客户端上可能呈现为不同的工具名，进而影响模型的名称匹配与日志可读性。加上 Claude Code 使用 mcp__<server>__<tool> 的调用前缀，服务器名称本身也会占用这段 64 字符预算，因此命名规范不只是风格问题，而是跨客户端兼容性的硬约束。

实践建议

基于这项测量，作者给出的建议与主流意见有显著差异：

不要为了准确率而削减工具。在前沿模型上，5 到 100 个工具没有体现出准确率差异。削减或延迟加载的理由是成本和上下文，不是准确率。

按动作和对象命名工具，不要用泛化动词。名称现在是模型读到的第一个信息，模糊的名称会带来额外的 schema 读取和错误调用风险。

写模型能区分的描述。这是保持 100% 准确率的关键——即使有近似工具和模糊名称，好的描述仍然让模型做出正确选择。

不要盲目分组。在你用户实际使用的客户端中测试，因为分组对 Claude Code 和 Gemini 的影响截然不同。

测量你自己的服务器。作者提供的 worklore story 包含了同样的基准测试步骤，可以让你的 agent 直接对你的服务器运行。

局限性

这项实验有其边界：使用的是假工具和单一领域（文件操作）；只测了三个前沿模型，没有测更小更老的模型（而调查中有测量的资料恰好集中在那些模型上）；任务是直接任务，没有长链推理，所以没有测量上下文拥挤效应；模糊名称只和好描述搭配测试，没有测双模糊的情况；token 计数包含每个客户端的开销；部分规模没有在每个通道都跑完，Codex 的模糊命名通道因为用量限制只有 60/72 次运行；而且这是 2026 年 10 月的时间切片。

尽管如此，这仍然是目前关于 MCP 工具数量最系统的公开测量之一。它至少说明一件事：在设计 MCP 服务器时，与其听从"越少越好"的经验法则，不如在你自己用户使用的客户端上做一次真正的测量。