Google API Gateway支持用API密钥保护MCP工具发现：列出工具与调用工具仍分开校验

2026年9月30日，Google Cloud宣布，API Gateway的MCP工具发现方法tools/list新增API密钥认证支持。此前可使用JWT认证，现在配置中也可以指定API-key安全方案。相关MCP能力仍处公开预览，要求使用OpenAPI 3.x描述；不能把这次新增认证选项理解为整个MCP服务已经转为正式可用。

先发现有哪些工具，再判断能调用什么

官方文档把两类请求明确区分：tools/list默认不认证，可以主动为它配置JWT或API密钥；tools/call则沿用底层API操作已有的认证策略。看到工具清单，与实际获得操作权限，是两项分别检查的事情。

使用API密钥保护工具发现时，客户端需要在x-api-key请求头中发送密钥，该方法不会从查询参数读取密钥。没有有效密钥的请求会收到JSON-RPC错误，也不会获得工具列表。接入方需要确认自己的MCP客户端能够按这种方式发送认证信息。

AI模型生成的概念示意图，表现工具目录入口受到访问控制，并非真实密钥、凭据或产品界面。

增加发现认证，也要复查暴露范围

一个重要配置细节是：将MCP扩展设置成对象形式来配置tools/list认证时，也会为所有符合条件的操作全局启用MCP。若不希望某些API成为工具，需要逐项显式退出。加上一道认证门，并不自动保证门后只留下原本打算开放的操作。

以下为本文分析。团队可以在变更前保存预期工具清单，变更后使用已授权的测试身份重新列出工具，核对名称、描述及数量。尤其要检查管理类操作是否随全局启用一并出现。这个核对比只看到认证请求成功更接近原来的配置目标。

验收应覆盖拒绝与成功两条路径

一轮小规模验证可以包括：未带凭据时不能获取清单；正确凭据能获取预期清单；获取清单后，调用某个受限操作仍按底层API规则判断。这样可以发现客户端把发现凭据误当成所有操作凭据，或者某项API本身缺少预期限制的问题。

返回结果也应按MCP协议读取。只看HTTP状态不足以判断某次工具交互是否完成，调用方还需要检查协议结果与错误信息，并保留能定位请求的记录。本文未部署或实测该配置，上述验收步骤是原创分析。

来源与核验

API Gateway官方发布记录日期为2026年9月30日；MCP配置文档说明预览状态、认证与全局启用行为。资料于北京时间2026年10月2日核验。