MCP 工具定义为什么每轮都在计费
WorkOS 转述 Anthropic 文档：GitHub、Slack、Sentry、Grafana、Splunk 五套服务的工具定义大约 5.5 万 token，且每次请求都占上下文。工具超过大约 30 到 50 个时，选错工具的概率会上升。
Maria Paktiti 在 2026 年 9 月 18 日的 WorkOS 文章里把 mcp 工具定义 token 写成一笔固定费用：工具的名字、说明和 JSON Schema 放在系统提示前缀里，每一轮都要再付一次，不是会话开始时付一次就结束。她转述 Anthropic 的数字：GitHub、Slack、Sentry、Grafana、Splunk 这种典型的多服务组合，在模型开始干活之前，工具定义大约就要 5.5 万 token。
第二笔是工具之间的中间结果
定义是固定成本。变动成本是两个工具之间流过模型的数据。文章举的例子是：从 Google Drive 取出会议记录，再写进 Salesforce。记录会先进入上下文，再作为下一次调用的参数整段送出。一次两小时会议，Anthropic 估计多出约 5 万 token，而真正要改的往往只是一个字段。载荷再大，会直接超出窗口；模型逐字抄写大结构时，还会抄错，成本问题变成数据错误。
她转述的另一条阈值是：可用工具超过大约 30 到 50 个，Claude 选对工具的能力会下降。文章建议在 10 个工具以上，或定义合计超过 1 万 token 时，考虑延迟加载；10 个以下且定义很短，普通工具调用就够。
文章列出的四种减负
按她排的顺序：
少暴露、按结果塑形。一个
track_order(email)在服务端自己调三个 REST 接口，比把三个接口都做成工具、让模型连调三次更省轮次。REST 接口多是给人写代码用的，搬进 MCP 之后每个接口都在抢同一次选择。defer_loading。模型先搜索目录，再展开当次需要的三到五个工具。文章转述 Anthropic：定义开销通常能砍掉 85% 以上，单次请求最多可挂 1 万个延迟工具。经 MCP 连接器接入时，延迟开关写在mcp_toolset的配置上，不是每个工具各写一次。仍要把完整定义放进请求的 tools 数组，变的是模型读到的上下文，不是你发出去的字节。全部延迟会得到 400，至少留一个不延迟的搜索工具。延迟工具不能带cache_control，缓存断点要打在未延迟的工具上。在沙箱里写代码调用工具，让大结果留在执行环境。文章转述的一个流程从 15 万 token 降到 2000。她同时写：这要真正的沙箱、资源限制和监控，只在中间载荷很大时才值得。
2026-07-28 的 MCP 修订要求
tools/list等结果带ttlMs和cacheScope，并保持工具顺序稳定。顺序若随 map 迭代变化，客户端的提示缓存会在每次重连时失效。
这些百分比都是 WorkOS 转述 Anthropic 文档或单次示例，不是本站复测。Opus 5.5 把缓存读取降到每百万 token 0.20 美元之后，前缀里的工具定义如果能命中缓存，单价会低一截，但选错工具的问题不会因为缓存折扣消失。