MCP Token费用重新测算：两份工具描述导致了该数值上升。
13天后对9台MCP服务器重新进行了测量：工具定义的token数量从36,320增加至38,738，几乎全部是由于其中一台服务器重新编写了其描述所致。
来源: We Re-Ran the Same 9 MCP Servers 13 Days Later. They Cost You 2,418 More Tokens.
2026年9月9日至22日期间，九款热门MCP服务器的工具定义总长度从36,320个标记增加到38,738个标记，增长了2,418个标记，增幅为6.7%，其中单款服务器就贡献了2,094个标记。工具的数量几乎没有变化，从108个增至109个。变化的是那些现有工具的描述文本长度。
核心数据
在首次测量13天后，使用完全相同的脚本再次进行测试，得到了以下结果：
- 九款服务器的工具定义总长度均增长了2,418个标记，增幅为6.7%。
- firecrawl-mcp的版本从3.24.0升级到3.25.2，保留的工具有27个，但仍贡献了2,094个标记。
为何现在这个问题如此重要
最近对MCP的批评声不断，其中核心诉求是服务器会悄悄增加智能体携带的上下文量。9月9日时已有一个基准数据，涵盖了9台服务器、108种工具以及36,320个标记，因此可以在9月22日再次进行相同测试。如今的上下文总量为38,738个标记，而几乎所有的增长都来自某台服务器——由于其现有描述变长，该服务器的工具数量并未变化。批评者正是以具体数字和公开的方法为依据提出这一观点的。
什么是标记成本
令牌税指的是在用户输入任何内容之前，工具定义所消耗的上下文预算。每台连接的服务器都会响应 tools/list 请求，其返回结果会被写入模型提示词中。在所监测的九台热门服务器中，2026年9月22日的总令牌数为38,738，而9月9日则为36,320。在20万令牌的窗口范围内，第一条消息出现之前就已经消耗了约19%的令牌，这一数值是某位开发者轻易就能设置出来的。
2026年9月22日18:29 UTC的快照显示：共有9台服务器、109个工具以及38,738个令牌。如需重现该数据，需逐一检查每个npm包的规格文件，然后使用o200k_base令牌化器统计严格意义上的名称、描述以及inputSchema载荷部分。
测量原理
每台服务器都是通过 npx 和 stdio 启动的。该流程会先发送 initialize 命令，再发送 tools/list 命令，并保存原始回复。对于每个工具，仅保留工具使用 API 实际接收的三个字段：名称、描述和 inputSchema。对象会通过排序键进行规范化处理，工具则按名称排序，最终序列化结果会以 o200k_base 作为计数基准。9月9日的测试也采用了同样的严格定义，且每台服务器都是在其2026年9月22日发布的最新版本上进行检测的。
系统会检测正在运行的服务器，而非直接读取其源代码，这两者之间存在实质区别。有些服务器会在运行时动态生成工具列表，通过标志来隐藏某些工具，或从模板中生成描述。因此，传递给模型的工具列表可能与仓库中的列表不同，而直接读取源代码得到的数值虽然看似合理，但实际上模型根本无法看到这些数值。检测方法也有其局限性：需要身份验证的服务器可能会向未登录的客户端显示较短的工具列表，而向已登录用户显示完整的列表。这次九个服务器都返回了完整的列表，但这种方法无法普遍排除这种可能性。
为何十三天的差异看似合理
有五台服务器在这段时间内没有产生任何输出，因此可作为内置的对照基准。这五台服务器分别是服务器文件系统、服务器内存、exa-mcp-server、tavily-mcp以及服务器序列思维，它们的数值分别精确回到了基准值：1,668、907、415、1,666和867个标记。并非接近基准值，而是完全等于基准值。如果存在数值漂移的探针或分词器，那么这五台的数值都会发生变化，因此2,418的增幅完全来自那四台有输出的服务器。
责任服务器
firecrawl-mcp在8月12日至9月22日期间发布了三次版本，共新增了2,094个token。@playwright/mcp通过两次版本更新以及一个新工具贡献了324个token。此外还有两个服务器版本发布，分别是@upstash/context7-mcp（两次版本更新）和@notionhq/notion-mcp-server（一次版本更新），它们的工具块大小完全保持不变。发布代码与改变传输的数据内容并非同一回事，后者只是偶尔发生。
功能更强大，还是只是更臃肿？
基本上只是变得更重了，而这正是大多数讨论中缺失的事实。firecrawl-mcp之前有27个工具，之后也是27个。它只是用两个工具替换了另外两个工具，这一变化导致评分减少了131个代币。额外的2,225个代币则来自那些功能相同的工具获得了更长的描述以及更大的输入结构。用户为原本就拥有的25个工具多支付了2,225个代币。
变化最大的两个工具的数值尤为显著：firecrawl_scrape的描述代币增加了721个，结构代币增加了462个；firecrawl_search的描述代币增加了691个，结构代币增加了234个。两者合计占2,225个代币中的2,108个。其余7个工具的代币变化总和仅为117个，还有16个工具的代币数值完全没有变化。由此可见，这并非整个生态系统在逐步提升，而是有两个工具的定义被大幅修改了。
这是否算作浪费取决于某个未被衡量过的因素。更详细的描述往往属于合理的修复行为：模型一直误用的工具问题得到了澄清，而令牌则提升了可靠性。不过，4,458个字符的长度大约相当于一整段散文，它与某个功能绑定在一起，并随每次请求一同传输。成本方面已经得到了准确衡量，而收益方面则仍不清楚。
令牌的实际去向
其分布特点是集中而非分散。按在38,738个令牌总数中的占比排序如下：
- Notion服务器以17,409个令牌的优势位居首位，占总量的44.9%，这些令牌分散在24个工具中。
- Firecrawl位居第二，拥有27个工具，共11,088个令牌，占比28.6%。
- Playwright紧随其后，25个工具对应3,734个令牌，占比9.6%。
- 参考文件系统服务器为14种工具使用了1,668个令牌（4.3%），而Tavily仅为5种工具使用了1,666个令牌（同样为4.3%）。
- Context7在2种工具上共使用了984个令牌（2.5%），内存服务器在9种工具上使用了907个令牌（2.3%），sequential-thinking则仅在1种工具上使用了867个令牌（2.2%）。
- Exa是最轻量的，仅有2种工具，使用了415个令牌，占比1.1%。
工具数量无法准确预测成本。@playwright/mcp提供了25种工具，但使用了3,734个令牌；而notion-mcp-server提供了24种工具，却使用了17,409个令牌。尽管工具数量几乎相同，但后者产生的费用却是前者的4.7倍。
对于那些需要运行两三台以上服务器的用户来说，关键问题在于哪些服务器属于Notion类型的。
这些批评正确吗？
就这一说法而言，在当前样本和时间范围内确实如此，不过其背后的机制比通常讨论的要狭窄。成本正在上升，而且是在没有新增功能的情况下上升的，这些成本集中在少数几台服务器上，而非分散在整个生态系统中。所谓MCP协议本身过于臃肿的常见观点与数据显示并不一致。数据表明，大部分成本实际上来自两家供应商的配套服务。
证据的局限性
- 没有显示出任何趋势。相隔13天的两个数据点仅能体现差异，无法反映发展轨迹，而且其中一个数据点受某一家供应商的版本更新影响极大。即便某个月份没有变化，数值也仍可能保持不变或出现负值，问题并不会因此消失。
对数值初稿的检验
第一次尝试采用了简单的序列化方式，直接使用返回的完整工具对象。对于9月9日的语料库，该方法生成的标记数为40,480，而此前已公布的数值为36,320。造成差异的原因并非服务器的变化，而是已公布的方法故意省略了额外的字段。
使用经过优化的严格定义重新运行后，得到了108个工具以及每单位36,320个标记数，因此出现了上述对比结果。对比两种不同的方法只会产生人为偏差，而非真实的测量值；在这里，这种人为偏差使得数值出现了6.5%的虚高，且方向更为明显。
针对该主题的早期研究也需保持同样的谨慎态度。此前有一篇研究报告称九台MCP服务器的token数为38,900，但该数值来自另一次运行，其方法并未经过重新验证，因此不能作为这里的基准值。38,738这一数值并非38,900的下降结果。唯一可以真正相减的数值对是36,320和38,738，因为这两个数值是由同一个脚本生成的。
常见问题
什么属于token费用？指的是在对话开始之前，客户端传递给模型的所有关于工具的信息：实际上每台服务器的工具/列表回复仅包含名称、描述和输入结构。除非客户端缓存了前缀，否则每次会话中的请求都会包含这些信息，即便没有调用任何工具也需要支付费用。
提示词缓存真的能使其免费吗？并非免费，只是更便宜而已，而且前提是前缀不会改变。在这九台服务器的96次版本发布中，有48%的版本升级改变了用于打开缓存前缀的工具块。频繁的版本发布意味着缓存需要频繁失效。
为什么notion-mcp-server的成本如此之高？它的24个工具都带有描述庞大API接口的输入架构，而且该工具块自7月以来一直未作任何修改。不存在功能扩展的情况。其成本从一开始就很高且一直保持不变，这与那些成本低但负载繁重的服务器是不同的问题，需要采取不同的应对措施。
未使用的工具可以关闭吗？有些客户端允许对服务器的工具进行筛选，从数据来看这是最有效的方案，因为去掉两台最昂贵的服务器就能让整体配置减少73.5%。不同客户的支持程度各异，因此在安装另一台服务器之前先确认这一点是明智的。
不到两周就增加6.7%算多吗？如果换算成一年时间的话听起来可能很惊人，但仅依据两个数据点来做预测会具有误导性。实际情况是，在某两个星期内，由于某个供应商的更新，九台服务器的配置增加了2,094个令牌，而且并没有新增任何功能。
今天就该做的一项检查
打开代理的MCP配置，统计服务器数量并找出最大的那个。上次更新时它的工具描述有变化吗？这种变化会被注意到吗？还有一个未解之谜：当客户端声称要过滤某个服务器的工具时，它实际上会发送多少个令牌？这个数值只是假设，并未经过验证。
相关阅读
- MCP服务器的两种故障方式及防止措施 — 过于宽泛的令牌范围和忽视任务需求的工具设计是导致大多数MCP故障的原因。通过限定令牌范围、进行使用者身份验证、处理经过过滤的错误信息以及设置工具使用上限，可以弥补这些缺陷。