MCP 接支付：怎样给 Agent 设计清楚的工具权限边界

开发者希望助手找到一张未付款账单，向用户展示报价，获得批准后再付款。把支付 API 封装成工具，确实能让助手使用这个流程。但还有一个更重要的问题：系统里的哪个环节，负责判断这张账单现在可以支付？

MCP 解决连接方式，真正的资金操作边界仍需要设计。

资料边界： 本文于 2026 年 11 月 1 日核对 MCP 官方文档，采用 2026-07-28 文档版本。以下是支付工具的设计分析，未测试某个 MCP 服务，也没有创建或使用支付凭证。

先定位 MCP 在应用里的位置

MCP 简介 将其定义为连接 AI 应用与外部系统的标准。架构文档 区分了 Host、由它管理的 Client，以及连接的 Server。服务端可以暴露工具、资源等能力，但协议不替应用决定业务规则。

接支付时，可以把 MCP 看成受控服务的接口。实际签名或支付处理能力应留在有明确检查的服务边界内，而不是让模型想调用什么，就直接对应一次资金操作。

支付工具边界概念图，非实测服务。策略和支付组件是应用需要设计的部分，并非 MCP 自带组件。

能访问服务器，不代表每笔款都获批

授权规范 讨论 HTTP 传输下的 MCP 授权，受保护的 MCP Server 在其中承担资源服务器角色；本地 STDIO 使用不同的凭证处理方式。接入方应先明确实际使用的传输与认证模式。

允许调用者访问服务的令牌，不应被解释为可以动用所有账户。对于账单流程，服务仍需把调用身份与客户、账户、具体操作和审批记录对应起来。“助手已连接”无法回答“谁批准了这笔付款”。

服务端还可能调用下游支付 API。MCP 的安全指南 提醒了令牌透传和混淆代理风险。签发给 MCP Server 的令牌，与下游服务认可的凭证，应明确区分，不能把收到的令牌当成到处都能使用的凭证包。

给助手一个小而清楚的操作流程

下面是建议的工具拆分，不是 MCP 官方支付 API：

工具职责	有用的返回内容	权限边界
查询账单	商户、金额、币种和当前状态	指定账户的只读访问
准备付款	固定的报价引用和有效期	不移动资金
执行已批准付款	尝试编号与当前结果	匹配审批并执行策略校验
查询执行结果	等待、失败或完成状态	只读核对

执行工具最好引用之前准备好的操作，而不是允许助手在批准后悄悄替换收款人或金额。报价过期或发生变化，应回到相应的确认环节。

这种拆分也让助手更容易准确描述结果。“已准备”可以表示方案存在，“已提交”可以表示有了付款尝试，两者都不需要被误写成“已付款”。

工具返回的是数据，不是新授权

供应商返回的账单描述里，可能夹着直接写给助手的指令。应用可以使用其中的账单数据，但不能让这些文本改写账户权限、变更已批准收款方，或要求提供凭证。

审查时，可以在模拟供应商响应里加入恶意指令，确认它不会被当作执行授权；同时测试错误账户引用、过期审批，以及超时后的重试。这些是建议测试项，我们没有针对某个服务执行它们。

MCP 调用与下游支付尝试之间应保留关联编号。提交后连接断开，优先走状态查询，而不是自动生成新购买。工具错误最好明确区分：没有执行任何动作、某次尝试已失败，还是结果仍不确定。

什么情况下值得引入

如果多种 AI 应用都要使用同一套定义清楚的工具服务，MCP 可以减少各自单独接接口的工作。若只是单个内部 Agent，也要衡量新增 Client/Server 与授权边界是否值得。

我们更建议按操作边界、凭证处理与结果核对能力评价支付 MCP Server，而不是数它暴露了多少工具。继续阅读 MCP 目录条目、A2A 的任务协作边界 和 支付幂等设计。