MCP 工具调用开始收费：Agent 接入 API 前，该先设计计费网关

MCP 让 Agent 接工具变得更顺手，也让一个老问题重新变得棘手：当调用者不再是人在网页上点按钮，而是一个可以连续执行任务的 Agent，API 应该怎么收费、怎么限额、怎么判断这次调用到底算不算一次可计费结果？

这个问题正在从架构讨论变成产品化能力。Cloudflare 7 月 1 日宣布 Monetization Gateway，目标是让放在 Cloudflare 后面的网页、数据集、API 或 MCP 工具可以通过 x402 收费。Zuplo 7 月 14 日给出了一套更工程化的 MCP 工具调用计费示例：不要把所有 MCP 请求都计费，而是识别 tools/call，按工具、套餐和结果成功状态扣减额度。Stripe 与 Tempo 早些时候发布的 Machine Payments Protocol 也说明，Agent 付费调用服务正在成为支付层需要支持的新场景。

对开发团队来说，重点不是马上接受某一种支付协议，而是先把计费边界设计清楚。只要你的 MCP Server 或 Agent 工具会消耗模型 Token、检索资源、浏览器会话、内部 API 配额或第三方服务成本，就不能只把它当成一个普通 HTTP 接口。

MCP 计费为什么比普通 API 更容易出错

传统 API 计费通常比较直接：哪个 key 调了哪个 endpoint，返回什么状态码，按次数、流量或资源用量计费。MCP 里会复杂一些。

首先，MCP 客户端连接后会先做初始化和工具发现。官方规范里，客户端通过 tools/list 获取工具列表，再通过 tools/call 调用具体工具。如果网关只看到同一个 /mcp 入口，就很容易把初始化、发现、心跳和真正的工具执行混在一起。这样一来，用户可能只是让 Agent 看一眼工具列表，也被当成一次付费调用。

其次，MCP 工具调用并不总是用 HTTP 状态码表达业务结果。一次调用可能在传输层返回成功，但工具结果里带着 isError: true。如果计费系统只看 200，就会把失败的上游查询、权限拒绝、参数错误都算进账单。对用户来说，这种计费最容易破坏信任。

第三，不同工具的成本差异很大。一个只读配置查询、一次数据库聚合、一次浏览器自动化、一段长上下文模型推理，不应该放进同一个“工具调用次数”桶里。Agent 会把多个工具串成任务链，单次任务的实际成本可能来自其中少数重型步骤。

计费网关要先回答五个问题

1. 谁在调用

Agent 调用 API 时，不能只知道“这是某个模型发来的请求”。需要把请求归因到用户、团队、应用、Agent、环境或客户。对外部开放的 MCP 工具，可以用 API key、OAuth、钱包凭证或协议层支付证明来识别调用者；对内部工具，也至少需要把调用和项目、成员、自动化任务关联起来。

这一步决定了后面所有治理能力：配额归属、成本归因、异常告警、账单解释、密钥轮换和审计追踪。

2. 哪些请求要收费

不要把 MCP 的所有协议帧都算钱。更合理的做法是把初始化、工具列表、ping、通知等协议流量视为免费，把真正执行资源消耗的 tools/call 作为候选计费事件。

即便都是 tools/call，也要继续按工具类型区分。轻量查询可以走基础额度，高成本推理、浏览器会话、深度检索、文件生成或第三方付费 API 调用，可以进入不同计量桶。这样套餐设计才不会被少数重型工具拖垮，也不会让轻量工具显得过贵。

3. 什么时候扣费

计费动作最好发生在结果确认之后，而不是请求进入时。入口处可以先做权限和额度检查，避免明显不允许的调用进入工具执行；真正扣费则等工具成功返回后再提交。

这可以避免两类争议：一种是用户没有权限却被扣费，另一种是上游服务失败也被扣费。对 Agent 场景尤其重要，因为它可能会自动重试或换工具。如果失败也计费，成本会在用户看不见的地方快速累积。

4. 超额时怎么返回

MCP 工具不只面对人，也面对会继续规划下一步的 Agent。额度不足、套餐不包含、工具暂不可用、需要人工确认，这些状态应该用 Agent 能理解的结构化错误表达，而不是简单丢一个模糊的 HTTP 失败。

例如，额度用完不是限流重试问题，而是策略问题；套餐不包含也不是服务器故障。清楚的错误语义能让 Agent 停止无意义重试，或者把“需要升级、授权或人工确认”的状态带回给用户。

5. 怎么审计和解释账单

如果用户问“为什么这次任务花了这么多”，团队需要能解释到工具级别：哪个 Agent、哪个任务链、哪个工具、哪次模型调用、多少 Token、哪个外部 API、是否触发重试或 fallback。

这不是财务报表的细节，而是产品体验的一部分。Agent 越自动化，用户越需要可解释的用量记录。没有审计日志，计费系统很难被信任；没有成本归因，团队也很难优化 Agent 的工具选择。

统一网关层为什么会变重要

把计费逻辑散落在每个 MCP Server 或每个业务工具里，短期看实现快，长期会很难治理。每个工具各自判断身份、额度、错误、扣费和日志，规则迟早会不一致。

更稳妥的做法是把 Agent 工具调用纳入统一网关层：入口统一鉴权，策略层判断是否允许调用，路由层决定走哪个工具或模型，计量层记录实际消耗，观测层把工具调用、模型 Token、延迟、失败原因和成本放在同一条链路里。

这也是 RouterHub 这类模型调用网关值得关注的地方。团队不一定一开始就要做复杂的支付系统，但至少应该先把模型 API、MCP 工具、成本归因、限额和审计收敛到同一个控制点。等工具开放给更多 Agent 或外部开发者时，计费只是这条链路上的一项策略，而不是每个服务临时补丁。

一个实用设计清单

如果你正在准备把 API 或内部能力暴露成 MCP 工具，可以先检查这几项：

每个调用能否追踪到用户、团队、Agent、应用和环境。
tools/list、initialize、ping 等协议流量是否不会被误计费。
不同工具是否能进入不同计量桶，而不是全部按一次调用处理。
权限和额度是否能在工具执行前拦截。
扣费是否只发生在工具成功返回后。
额度不足、套餐不包含、需要确认等状态是否能被 Agent 读懂。
日志是否能解释一次任务的模型、工具、Token、重试和成本。
出现异常消耗时，是否能按 key、Agent、工具或模型快速暂停。

这些问题解决之前，不建议把高成本工具直接开放给自主 Agent。否则最先暴露的问题可能不是支付协议选错了，而是账单、权限和责任边界都说不清。

结论

MCP 的价值在于让 Agent 更容易连接工具，但工具一旦进入真实业务，就会自然走向计量、限额、支付和审计。Cloudflare、Zuplo、Stripe/Tempo 的近期动作说明，Agent 付费调用 API 和 MCP 工具正在从概念变成基础设施能力。

真正的变化是：API 的“使用者”正在从人和应用，扩展到能自动决策的 Agent。团队需要提前把工具调用当作生产流量来治理。先设计清楚身份、计量单位、成功扣费、额度策略和可观测性，再谈开放给更多 Agent，风险会小得多。