Google 于 2026 年 9 月 24 日推出 Cloud API Gateway 的 MCP 公开预览能力，可通过配置把已有 REST API 暴露为 Agent 工具。接入要求使用 OpenAPI 3.0.x 或 3.1.x；仍使用 2.0 的接口文档需要先迁移。ERP、CRM 接口应先验证兼容性，再确定试用范围。Google 开发者公告
接口能够调用之后，仍要回答“这次调用在业务上意味着什么”。查询库存、预留库存和确认出库可能只差一个接口，但对实际业务的影响完全不同。
业务动作的选择
建议围绕一个完整任务选择接口，例如“查询某订单可用库存并生成补货草稿”。先开放必要查询，再根据授权范围提供写入动作。不要把接口目录中的所有端点直接作为员工可用工具。
| 动作 | 必要条件 | 成功结果 |
|---|---|---|
| 查询库存 | 物料、仓库、统计口径 | 数量与查询时点 |
| 创建草稿 | 物料、数量、业务主体 | 草稿编号 |
| 提交审批 | 草稿版本、提交人权限 | 审批实例编号 |
| 撤销申请 | 当前状态允许撤销 | 撤销状态与原因 |
工具名称和说明应帮助模型区分这些动作，避免用“处理订单”一类含糊名称承载多个不同操作。
参数的业务含义
OpenAPI 可以规定字段类型，但整数类型不能说明它代表箱数还是件数。应在参数说明中补充单位、编码来源、允许范围和空值含义。
日期字段需要明确时区以及它表示业务发生时间还是录入时间。组织字段需要说明是签约主体、使用部门还是仓库归属。默认值涉及业务后果时，应公开展示并经过确认。
身份与授权
工具发现和工具执行需要分别检查。当前预览版本的 tools/list 默认无需鉴权，会暴露工具名称和参数结构；正式环境应为它配置 JWT，API key 不能保护该方法。tools/call 继续执行底层 REST 接口的鉴权规则。业务系统还需核对请求者能操作哪些对象，并保留真实发起人与服务账号的关联。
如果采用服务账号代理，应在后台对请求者、工具范围和业务对象做明确检查，并保留审计关系。工具描述中的“只允许查看本人数据”不能替代服务端校验。
重复提交与未知结果
网络超时不等于业务失败。请求可能已经被 ERP 接收，只是回执没有返回。写入接口应提供业务请求标识和结果查询方式，使 Agent 能核查已经生成的单据。
示例：创建补货草稿超时后，先用请求编号查找结果。找到已有草稿则返回该草稿，确认未执行才按规则重试。不能每次重试都生成一个新编号，把重复单据留给人工清理。
交付时的验证样本
至少检查正常参数、缺少关键字段、权限不足、对象状态已变化、重复请求和外部系统超时。错误信息应给操作者可理解的处理建议，同时为维护人员保留诊断信息。
最后从业务系统独立查询终态，核对对象、金额、数量和状态。工具返回成功只能说明调用链给出了成功响应，正式业务结果还要能回读确认。
接口建设可参考面向 Agent 的接口交付清单和写后回读验证。已有 ERP 的接入范围可在业务系统定制中按具体动作约定。
