实测 MCP 工具开销：26 个工具每次调用 $0.03
目录
Agent 只要接入一个 MCP server，还没开始执行任务，每次调用就已经产生额外费用：GitHub server 的 26 个工具在每次 Claude Opus 4.8 调用中都会产生 $0.0302，无论实际是否使用工具。这个过程不会直接显示出来，只有查看计量数据才能发现。开销大小与所用模型的关系，比接入多少工具更大，而且大部分可以通过缓存消除。我们测量了整个链路：五个模型系列、五个真实 MCP server、从 0 到 40 个工具的合成阶梯，以及降低费用所需的缓存和精简手段。
TL;DR
- 每次 API 调用都会将工具定义作为输入 token 重新计费；在 Claude Opus 4.8 上，一个小工具实测占 401 token。
- 同一套工具在 Claude 上消耗的 token 是 GPT-5.6 的 2.7 倍（实测每个工具分别为 173 和 64）。
- 真实的 GitHub MCP server（26 个工具）在 Opus 4.8 上每次调用收费 $0.0302，在 Gemini 3.6 Flash 上则为 $0.0029，相差 10 倍。
- 显式缓存可将持续携带的工具块成本降至十分之一，但低于缓存门槛的工具集无法缓存，而且只要修改一个工具，整个工具块都会重新计费。
MCP server 如何变成输入 token？
整个过程分为三个阶段。只有最后一个阶段收费，但每次调用都会重复。先明确范围：MCP server 会暴露三种原语，即工具、资源和 prompt。只有工具会产生持续费用，因为 API 的 tools 参数必须在每次请求中携带所有 schema。资源和 prompt 没有自己的 API 字段，只有内容实际加入对话时才消耗 token。第一阶段是 MCP 协议本身：Agent client 通过 JSON-RPC 向 server 请求 tools/list 并获取 schema。每个 session 只执行一次，不会调用模型。第二阶段由 client 将这些 schema 转换为 API 的 tools 参数，同时丢弃 annotations 和 outputSchema 等 MCP 专用字段，仍然免费。第三阶段中，由于 API 无状态，模型无法记住有哪些工具，provider 必须在每次请求时将这些 schema 渲染为隐藏的 prompt 文本。无论是否使用工具，这部分文本都会在每次调用中按完整输入费率计费。
最简单的示例是：在 Opus 4.8 上，user message 只有 “Reply OK” 的请求会消耗 11 个 prompt token。加入一个普通的 get_weather 工具，包含两个参数和一行描述后，同一请求会消耗 412 个 token。仅这一个工具，就会让每次调用多出 401 token 和 $0.002。更值得关注的是发送内容与计费量之间的差异：工具 JSON 本身只有约 130 token，但 provider 渲染后接近其三倍。
每个模型上的单工具成本是多少？
模型带来的差异远超大多数团队的预期。我们将完全相同的合成工具集发送给五个模型系列。每个工具都包含三个参数和一行描述，工具数量从 0 逐级增加到 40，再根据计费增量进行测量：
| 模型 | 固定开销（启用工具） | 每个工具的边际开销 | 40 个相同工具 |
|---|---|---|---|
| Claude Opus 4.8 | 290 | 173 | 7,210 |
| GLM 5.2 | 96 | 120 | 4,896 |
| Kimi K3 | 37 | 99 | 3,997 |
| Gemini 3.6 Flash | ≈0 | 72 | 2,871 |
| GPT-5.6 Terra | 98 | 64 | 2,658 |
相同工具相差 2.7 倍：Claude 在这组模型中渲染的工具框架最冗长，GPT-5.6 最精简。与实际发送的 JSON 相比，偏差也可能朝两个方向发展：按照传输 payload 字节数除以四进行粗略估算，Claude 的计费量约为该估值的 1.36 倍，而 GPT-5.6 和 Gemini 只有约一半。不同模型系列对工具块的 token 计算结果无法通用，因此应该按模型做预算，而不是按 schema 做预算。
真实 MCP server 每次调用要花多少钱？
下表列出了官方 MCP repository 中五个未经修改的真实 server。我们使用标准字段映射进行转换，并测量了每次调用持续携带这些工具产生的开销：
| MCP server（工具数） | Opus 4.8 | GPT-5.6 Terra | Gemini 3.6 Flash | Kimi K3 | GLM 5.2 |
|---|---|---|---|---|---|
| GitHub (26) | 6,043 tok / $0.0302 | 2,076 / $0.0052 | 1,931 / $0.0029 | 3,152 / $0.0095 | 4,077 / $0.0022 |
| Filesystem (14) | 2,785 / $0.0139 | 1,254 / $0.0031 | 1,200 / $0.0018 | 1,574 / $0.0047 | 1,772 / $0.0010 |
| Everything (13) | 1,942 / $0.0097 | 798 / $0.0020 | 663 / $0.0010 | 970 / $0.0029 | 1,176 / $0.0006 |
| Memory (9) | 1,670 / $0.0083 | 554 / $0.0014 | 491 / $0.0007 | 815 / $0.0024 | 1,057 / $0.0006 |
| Sequential-thinking (1) | 1,764 / $0.0088 | 912 / $0.0023 | 815 / $0.0012 | 870 / $0.0026 | 1,015 / $0.0006 |
最后一行反映了两个问题。Sequential-thinking 只暴露一个工具，但在五个模型系列中的四个上，开销仍高于拥有九个工具的 Memory，原因是它唯一的工具描述极长：衡量指标不是工具数量，而是渲染后的大小。第一行则最容易让 Agent 开发者意外：一个包含 10 次调用的 Agent episode，如果全程携带 GitHub 工具集，在 Opus 4.8 上会产生 $0.30，在 Gemini 上则为 $0.03。实际任务还没开始，两者就已经相差整整一个数量级。GLM 5.2 的 token 计费量是 Gemini 的两倍多，但最终金额更低。更便宜的标价足以抵消冗长的渲染结果，因此 token 和金额必须分开做预算。
Agent 实际会用到工具集中的多少工具？
每次调用通常只会用到很少一部分，这正是这笔开销显得不合理的原因。在我们的 Agent suite 工具场景中，一个典型 episode 包含三次调用，八个工具会随每次调用一起发送，但每次最多只调用其中一个：为了使用一个 schema，每次调用都要为八个 schema 付费。按照 Opus 4.8 的实测费率，这个八工具块每次调用约占 1,674 token，整个 episode 仅携带 schema 就要消耗约 5,000 token。工具循环场景相对理想：共有三个工具，几乎每次都会调用，但整个工具块仍要随循环中的四到五次调用重复发送。记录反映出的普遍规律是：每次调用很少会使用超过一个工具，因此工具集的单次调用成本取决于接入了什么，而不是 Agent 实际执行了什么。
缓存能否抵消工具开销？
在合适的模型上，大部分可以抵消，但我们实测发现了三个明确限制。在 Claude Opus 4.8 上，工具块是可独立缓存的前缀。我们为最后一个工具标记 cache_control 后，20 个工具组成的工具块只需写入一次，包含 3,682 token，并按 1.25 倍的写入费率计费。后续每次调用均以 0.1 倍费率从缓存读取，有效携带成本降低 90%。Kimi K3 的自动缓存无需任何配置，效果甚至更好：第二次调用中，工具块的 2,112 token 有 2,048 个来自缓存，占 97%，仍采用其常见的 256-token 分块方式。我们在该模型系列首日测试中发现，GPT-5.6 的显式断点采用相同定价结构：写入为 1.25 倍，读取为 0.1 倍。Gemini 的隐式缓存也符合我们此前测得的其他结果：预热后对工具块进行三次探测，命中次数均为零。这里的折扣只能视为意外返还，不能纳入计划。
这三个限制分别是：第一，缓存门槛。Claude 上由两个工具组成的工具块约为 655 token，低于 1,024-token 的最低缓存门槛，因此即使显式标记也完全无法缓存。是否能使用缓存，取决于各模型的最低门槛。第二，变动问题。工具块位于 prompt 最前面，只要修改工具列表，后面的所有缓存都会失效。我们直接测量了这个代价：在 Claude Opus 5 上向已缓存的 20 工具集添加一个工具后，整个 4,082-token 工具块都会按写入溢价重新写入。整个 session 应固定工具列表，否则每次变更都要承担重写成本。第三，Anthropic 的对话中途修改工具 beta 功能正是为解除这一限制而设计。该功能已在 Opus 5 文档中说明，允许在轮次之间修改工具而不导致缓存失效。对于大量使用工具的 Agent，这是最值得关注的功能。
如何缩小工具块本身？
优先减少参数，而不是精简描述。在我们的 20 工具块中，将描述缩短为一个简洁分句可节省 10%；将每个工具从三个参数减少到一个可节省 34%；两者同时调整则可节省 44%，从 3,768 token 降至 2,128。大部分 token 都消耗在参数 schema 上，包括名称、类型和嵌套描述。这与常见做法相反：团队通常会反复润色描述，却放任 schema 不断膨胀。
效果更明显的办法是，不要接入不会使用的工具。每接入一个 MCP server，每次调用都会增加其完整工具块；多加一行配置，就可能让这笔开销翻倍。如果 client 支持过滤，可以只注册 server 的部分工具，额外费用大致会按比例下降：GitHub server 有 26 个工具，只保留其中五个后，按照该 server 的平均工具大小估算，Opus 4.8 的费用会从 $0.0302 降至 $0.007。如果使用多个模型系列，还要考虑上文的 2.7 倍差距。同一个 Agent 从 Gemini 迁移到 Claude 时，如果没有重新做预算，其工具携带 token 几乎会增至三倍。
常见问题
MCP 本身会增加 token 成本吗？
不会。MCP 协议、发现过程、JSON-RPC 和工具调用链路都不会接触模型，因此不产生任何费用。只有当 client 将 server 的 schema 转发到 API 的 tools 参数后，才会产生费用。provider 会在每次调用中将这些 schema 重新渲染为计费的 prompt 文本。MCP 带来的影响在于规模：接入 26 个工具只需一行配置，此后的每次调用却都要携带全部 26 个 schema。
未使用的工具也会产生费用吗？
会，费用与已使用的工具完全相同。模型必须在每次调用中读取所有 schema，才能知道自己可以调用哪些工具。我们的 Agent suite 记录显示，每次调用最多只会调用一个工具，但每次都会为完整工具集计费。已经接入但处于闲置状态的 server 只会产生携带成本。缓存可以降低这部分费用，但只有精简工具或断开连接才能彻底消除。
MCP 资源和 prompt 会像工具一样消耗 token 吗？
不会。只有工具会产生每次调用的携带成本，因为 tools 参数会在每个请求中重新发送所有 schema。只有 client 读取资源并将其内容插入对话时，资源才会计费。此时它就是普通输入，定价方式与其他检索文档相同，并适用同样的分层原则：易变的资源内容应放在缓存断点之后。Prompt 模板也只有在调用时才会收费，计费对象是模板生成的文本。已连接 server 中未使用的资源和 prompt 不产生费用。因此，当 MCP 集成开始出现在账单中时，应优先检查工具。
修改工具列表会导致 prompt cache 失效吗？
会，缓存会完全失效。工具块渲染在 prompt 顶部，因此任何修改都会导致工具块及其后方所有缓存内容重新写入。我们实测添加一个工具后，整个 4,082-token 工具块会按 1.25 倍溢价重新计费。每个 session 应固定工具列表，并将工具列表变更集中处理。同时应关注 Anthropic 的对话中途修改工具 beta 功能，它专门用于消除 Opus 5 上的这项成本。
测量时间为 2026-07-31，测试通过 Synthorai gateway 完成：在五个模型系列上测试了合成工具阶梯（0-40 个工具，n=2）和五组真实 MCP server 工具集（通过 JSON-RPC tools/list 从官方 server 实时获取 schema）；缓存探测采用加盐前缀，并按单次调用拆分缓存明细；Agent 工具利用率来自Agent 成本研究所用 suite 的记录。GPT-5.6 缓存倍率来自我们首日发布的成本指南测量结果。金额为从 gateway 计量器读取的计费成本差值，按输入标价计算。费率和渲染行为可能变化，请用自己的使用记录验证。