MCP服务器工具列表的Token成本：34,374份清单实测

每个AI模型请求都会重新发送MCP服务器的完整工具列表——这份"隐形开销"究竟有多大？一项覆盖34,374个服务器的实测给出了答案：中位数约1,300 token，但最重的清单高达54万token，足以撑爆上下文窗口。

MCP服务器工具列表Token成本实测

为什么工具列表会成为成本项

MCP（Model Context Protocol）让AI客户端连接外部工具服务器，服务器的tools/list定义了它能提供哪些操作。问题在于，客户端在每次模型请求时都会把这份列表完整塞进提示词。

此前一项对12,915个MCP服务器的调查显示，182,157个工具定义分布在7,656个服务器上，平均每个服务器约24个工具。有读者据此追问：如果每次请求都要重发，这份列表的token成本到底是多少？

HISTOR（公开的MCP服务器日志）决定不做抽样，而是全量统计：截至2026年10月19日，覆盖18,204个npm和PyPI包以及16,170个远程服务器。

MCP 的 tools/list 返回的是结构化的工具定义数组，每个定义通常包含 name（工具名）、description（自然语言描述）和 input_schema（JSON Schema 格式的参数规范）。客户端会把这整个数组序列化后嵌入系统提示或专用字段，因此 token 消耗本质上等于这些 JSON 文本的长度。JSON Schema 允许嵌套对象、枚举、默认值和描述字段，一个参数复杂的工具其 schema 本身就可能包含数百个 token。

这也是为什么“工具数少但 token 多”的现象成立：一个工具若有十几个参数、每个参数都带 description 和枚举约束，其 schema 体积可以远超十个只有单个字符串参数的工具。理解这一点，才能判断削减成本应从压缩描述还是重构 schema 入手。

统计方法

计数方式模拟客户端构造请求的过程：对每个工具取其name、description和input_schema，序列化为紧凑JSON后计算token。分词器使用o200k_base（tiktoken 0.12）。每个至少含一个工具的服务器计一次，采用HISTOR最后一次观测到的列表。

核心数据：中位数便宜，长尾惊人

指标	包（Packages）	远程服务器
服务器数	18,204	16,170
工具定义总数	337,449	232,427
每服务器工具数（中位/均值）	8 / 18.5	7 / 14.4
每服务器token中位数	1,272	1,328
均值	3,812	3,412
90分位	8,361	7,425
99分位	39,612	22,294
最大值	304,780	547,935

三个发现值得注意。

均值是中位数的三倍。 典型服务器很便宜，但少数拥有成百上千个工具的服务器贡献了大部分token。原先调查中的"约24个工具"是均值，扩大到更大数据集后，均值降至18.5，中位数仅8。

最重的列表未必工具最多。 最大的远程列表包含71个工具却占用547,935 token，约每工具7,700 token；另一个远程服务器15个工具就占了175,588 token。让列表变重的是单个定义的体量，而非工具数量——当每个工具要花数千token时，一条描述或一个输入schema本身就成了一篇文档。

有些列表根本装不下。 304,780 token已超过20万token的上下文窗口，客户端一旦连接该包，连提问的空间都不剩。

换算成真金白银

工具列表随每次请求发送，成本等于token数×单价×请求数。按2026年10月19日的标价，每1,000次请求的成本如下：

单个服务器的列表	Tokens	$0.10/百万（小模型）	$2/百万（中型模型）	中型模型走提示缓存
中位数包	1,272	$0.13	$2.54	$0.13
均值包	3,812	$0.38	$7.62	$0.38
90分位	8,361	$0.84	$16.72	$0.84
99分位	39,612	$3.96	$79.22	$3.96

连接五个中位数服务器的客户端，在用户敲下第一个字之前，就已经发送了约6,400 token的工具定义。

提示缓存（prompt caching）是主流模型 API 提供的一种计费优化：当请求的前缀部分（通常是系统提示和工具定义）与上一次请求完全一致时，提供商可以复用已计算的 KV 缓存，从而按远低于输入价的价格计费。文章提到的“二十分之一”是常见的缓存读取折扣量级，具体比例因提供商而异。

缓存命中的关键条件是前缀逐字节稳定。如果客户端每次请求都重新序列化工具列表、调整工具顺序或在列表前插入动态内容（如时间戳、用户状态），缓存就会失效，按全价计费。因此提示缓存不是自动生效的省钱手段，而是一种需要客户端在请求构造层面刻意维护的工程约束。

如何削减这笔开销

提示缓存。 如果客户端保持工具列表不变且放在提示词靠前位置，缓存读取价格约为输入价的二十分之一。但一旦客户端重排工具顺序、或每次请求重建列表，这份优惠就没了。

按需加载定义。 模型先只看到工具名称，真正准备调用时才获取schema。

发布者缩小定义。 描述只说明工具做什么、何时使用，别的不写；schema避免重复的散文式说明；减少工具数量，或把相关操作合并到一个带action参数的工具后面。包内工具token中位数是129，远程服务器是231——每工具7,700 token的清单，显然另有隐情。

“按需加载定义”在工程上通常对应两种模式。第一种是两阶段调用：首次请求只暴露工具名称和一句话用途，模型选定工具后再发起一次请求获取完整 schema 并执行，代价是多一次往返。第二种是工具检索：将工具列表视为可检索的语料，根据用户 query 先做向量或关键词检索，只把最相关的若干工具定义注入提示词。

这两种模式都牺牲了一部分“模型一次看全所有能力”的便利性，换取上下文和成本的节省。对于工具数量少（如中位数 8 个）的服务器，直接全量发送仍然划算；按需加载的收益主要在工具数多、单定义重的长尾服务器上才显现。

自己动手测量

项目方在modelmarket.dev/tools/tool-list-cost提供了免费计数器：粘贴一段tools/list，或指定一个HISTOR观测到的服务器（https端点、npm:<package>、pypi:<package>或注册表名称），即可得到token数、在34,374个服务器中的排名、每千次请求成本、最重的工具，以及一行可放进README的徽章代码。

该页面使用与上述数据相同的分词器，并在HISTOR的120份工具列表（共260万token）上与tiktoken做过比对，结果零差异。粘贴的列表仅在内存中计数、不会被保存；查询只访问HISTOR，不会联系目标服务器。

这些数字没有衡量什么

只用一个分词器。 其他模型计数不同，通常相差数十个百分点，但整体形状一致：中位数接近1,300 token，加一条长尾。
未计入提供商自身文本。 模型API会用自家指令包裹工具定义，这部分未统计。
客户端实际发送的内容可能有出入。 有些会丢弃字段或截短描述，有些还会发送输出schema。按完整列表计算，包的列表中位数为1,390 token，90分位为9,960。
未区分服务器流行度。 每个列出的服务器只计一次，热门服务器和废弃服务器权重相同。

分词器差异值得展开：o200k_base 是 OpenAI 系列模型使用的 BPE 分词器，而 Claude、Gemini 等模型使用各自的分词方案。JSON 和代码类文本在不同分词器下的切分粒度差异通常比自然语言更明显，因为标点、下划线和驼峰命名会被不同地合并或拆分。数十个百分点的偏差意味着本文的绝对值不能直接套用到其他模型，但中位数约 1,300 token、均值数倍于中位数、存在极端长尾这三个结构性结论在不同分词器下保持稳健。

可复现性

方法与五种语言的实现见alexar76/histor仓库的docs/tool-list-cost.md，计数脚本为scripts/tool_list_tokens.py（导出查询写在其docstring中），不含服务器名称的汇总数据在docs/tool-list-tokens-2026-10-19.json。

对MCP生态的开发者而言，这份数据传递了一个清晰信号：工具列表不是免费的元数据，而是每次对话都要重新支付的通行费。设计工具时对描述和schema保持克制，客户端侧善用缓存与按需加载，是当下最直接的两个省钱杠杆。