MCP 不该再是另一套后端，Google 把它塞进了 API Gateway

一个 Java 服务已经跑了三年。

它有 OpenAPI 文档，有 API Gateway，有 JWT、API Key、限流、审计日志，还有一堆在生产事故里磨出来的鉴权规则。现在团队想让 Agent 查订单、查库存、创建工单。多数人的第一反应，是再起一个 MCP Server，把那几个 REST API 包进去。

然后问题就开始长出来。

MCP Server 用谁的身份访问下游。它的权限和网关是不是同一份。限流算哪边。审计日志里，用户先调用 Agent、Agent 再调用工具，这条链路还能不能拼回去。等到接口改版，OpenAPI 改了一次，MCP 的 schema 又改一次。你以为只是多写了个 Adapter，实际是多养了一套会逐渐走样的控制面。

Google Cloud 在 9 月 24 日把 API Gateway 的 MCP 支持放进 Public Preview。它干的事不花哨，却正好捅在这个工程痛点上。已有 REST API 不用改后端，只要在 OpenAPI 3.x 里标注，就能由 Gateway 暴露成远程 MCP Server。

我觉得这比又一个 Agent 框架更值得开发团队花时间看。

因为 Agent 真正难接入的，从来不是模型会不会调用工具。难的是让它在已有系统的边界里调用工具，而且别把过去几年补上的安全和治理，一夜之间绕开。

MCP Server 经常是复制粘贴出来的第二个网关

MCP 的确把工具接入标准化了。客户端用 tools/list 发现能力，用 tools/call 调用能力，模型不必理解每家内部 API 的奇怪约定。对于本地脚本、个人工具、没有既有服务的小团队，这套模型很轻。

可一旦进企业服务，事情不是这样。

一个订单查询接口，表面上是 GET /orders/{id}。背后可能有租户隔离、用户身份校验、按客户等级的 quota、敏感字段脱敏、审计事件、灰度规则。你给 Agent 写一个 MCP Tool 时，往往会把这些逻辑再接一遍。有些团队写得很认真，会做 token 透传、统一 traceId、重新实现请求校验。有些团队赶进度，直接用服务账号把后端打通。

后一种一开始特别顺。

等到第一个越权工单出现，或者财务问一句「谁在什么时间，用什么身份调了退款接口」，这条顺路就会变成排查现场。不是 MCP 有问题，而是新协议被当成了新入口，原来的入口治理没有跟过去。

Google 这次选择的是反过来处理。API Gateway 接到 MCP 的 JSON-RPC 请求，把 tools/call 转成对应的 HTTP REST 请求。之后它走的还是原有 Gateway 路径，JWT 或 API Key 鉴权、quota、日志、后端路由都不换。官方说得很直白，MCP 和 REST 共用一条 policy path，同一个 operation 无论从哪种协议进来，都消耗同一份 quota。

这件事看着像协议转换，工程含义其实更重。

它把 Agent 接入从「新建一套工具服务」变成「给既有 API 增加一种受控调用方式」。对已经有 Spring Boot 服务和网关体系的团队，后者显然更像正路。你不用相信一段新写的 glue code 会永远和生产规则一致，只要让它根本没有机会分叉。

OpenAPI 不再只是给人看的接口说明

这项能力的入口是 OpenAPI 3.0 或 3.1。OpenAPI 2.0 不支持，存量 API 要先迁移。文档级用 x-google-api-management.mcp 打开 MCP，再在 operation 级用 x-google-mcp-tool 决定是否暴露、怎么暴露。

一个订单查询接口大致会长这样。

openapi: 3.0.4
x-google-api-management:
  mcp: true
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: 返回订单状态、物流承运商和预计送达时间
      x-google-mcp-tool:
        name: get_order_status
        description: 当用户询问订单到了哪里或何时送达时使用

这里有个容易被低估的细节。官方要求每个暴露的 operation 都有 backend 和非空 description，并且特别提醒，description 是 LLM 决定何时调用工具的主要信号。

很多 API 文档里的描述是「查询订单」。给人看勉强够，给模型用就太含糊了。模型需要知道触发条件、输入的业务含义、哪些场景不该调用。比如订单号是否必须来自当前用户的上下文，查询失败时能否重试，结果是不是包含隐私字段。这些并不是文案润色，而是 Agent 行为的边界条件。

我一直觉得，Agent 时代最容易被误解的一件事，是把 prompt 和 tool description 当成非工程资产。它们实际上正在成为运行时策略的一部分。写得模糊，模型就会在边界上猜。猜对了像智能，猜错了就是事故。

如果团队有 API Design Review，x-google-mcp-tool.description 应该进 Review 清单。别只问接口能不能调，也问 Agent 在什么用户意图下应该调、绝不应该调。

发现能力可以公开，调用权限不能糊涂

这次 Preview 最有价值的提醒，反而藏在 tools/list 的默认行为里。

默认情况下，工具发现不需要认证。开发时当然方便，MCP Client 一接地址就能知道有哪些工具和参数 schema。但放到生产里，这等于把工具名与输入结构公开给任何来问的人。订单、退款、员工目录、内部报表，光是名字和字段就足够给攻击者提供地图。

Google 的建议是，生产环境给 tools/list 要求 JWT。这里还有一个坑，API Key 不能用于保护这个 discovery 方法。与此同时，tools/call 始终执行底层 REST operation 自己要求的认证。

这会带来两层不同的决策。

第一层是可见性。谁可以知道系统有哪些工具。

第二层是执行权。即使知道存在 approve_refund，谁又真的可以发起退款。

不少团队只盯第二层，因为它看起来更危险。但第一层泄露后，攻击者的枚举成本会急剧降低。特别是 Agent 工具往往比面向用户的 Web API 更贴近业务动作，名字也更直白。

你如果正在给 LangGraph 或 Spring AI 接内部工具，我建议做一次很朴素的盘点。把 Tool 列出来，给每一个标三个字段，发现权限、调用身份、审计归属。没有这三项的工具，不该因为「演示能跑」就进生产。

这套方案省掉了什么，也没有省掉什么

它省掉的是协议层的重复劳动。

你不再需要维护独立 MCP Server 的部署、鉴权桥接、API schema 同步和一套平行日志。对于 Cloud Run 加 API Gateway 的小服务，接到 Agent 的路径确实短了很多。对于已有网关治理的团队，风险也更可控，因为 policy 不必复制。

但别把 Public Preview 当成一个全功能 MCP 平台。官方当前支持远程 MCP Server、HTTP POST、从 OpenAPI 3.x 生成配置，以及 initialize、initialized、tools/list、tools/call 这几个生命周期方法。MCP resources、prompts、响应 streaming 还不在当前能力里。

限制也很具体。HTTP 204 这类空响应的 operation 不会被暴露。嵌套很深的对象 schema 在 tools/list 里可能展示不完整。单个 Gateway 最多服务 1000 个工具。更别扭的一条是，MCP 和 Model Routing 不能放在同一份 API config。

最后这条会让不少平台团队停一下。一个 Gateway 本来既可能承接 Agent 到业务 API 的出站调用，也可能承接应用到模型的调用。现在两者得拆配置，甚至拆网关。它不优雅，但至少是清楚的产品边界。比起在一个配置里悄悄互相影响，明确限制反而更容易设计出可靠架构。

还有一个现实问题，OpenAPI 不是天生适合 Agent 的 schema。给前端用的 API 常见大 payload、冗长参数、字段名靠上下文理解。模型调用工具时，输入结构越复杂，失败概率越高。不要因为 Gateway 能自动映射，就把全部 REST API 一键暴露出去。

这条路走不通。

更稳的做法是先选几个窄而高频的 operation。查订单、查库存、创建低风险工单，这类工具输入短、结果可解释、授权边界明确。先把 trace、拒绝路径、失败重试、人工接管跑通，再考虑写操作和跨域流程。

对 Java 和 Spring 团队，切口不在代码而在契约

假设你有一个 Spring Boot 的订单服务。过去的链路是浏览器或 App 调 API Gateway，Gateway 验 JWT、限流，然后转发到 Controller。现在要接一个客服 Agent，最差的做法是再写一个 McpOrderServer，里面调 Feign Client，自己拼 User Context。

不是说不能写。很多时候私有协议、复杂编排、非 REST 能力，还是得自己实现 MCP Server。

问题在于，不需要自己实现的那部分别重复实现。

如果已有服务的 operation 是清晰的 REST 接口，Gateway MCP 可以把 Agent 接到同一个端点。Agent 的 MCP 请求落到 /mcp，Gateway 把工具参数映射到 path、query、body、headers，再沿用既有 policy 发给后端。Spring Controller 感知不到 MCP，它只接到一个经过同样认证与治理的 HTTP 请求。

这样团队真正该投入的地方就显形了。