1. 项目概述这不是一次普通的产品更新而是一次架构级的范式转移你可能已经注意到 Google Cloud 官方博客里那句轻描淡写的公告“API Gateway 公测版支持将 REST API 直接暴露为 MCP 工具”。乍看之下它像极了又一个“支持新协议”的常规功能迭代——毕竟 Google Cloud 每季度都要发布几十项更新。但如果你在去年深度参与过 OpenAI 的 MCPModel Context Protocol早期开发者计划或者正在用 Playwright、Burp Suite、Figma 或 Blender 构建 AI Agent 工作流这句话的分量就完全不同了。它意味着你不再需要自己写一个中间层服务去把 OpenAPI 文档翻译成 MCP 格式也不再需要维护一套独立的 MCP Server 来桥接模型与后端系统Google Cloud 的 API Gateway现在本身就是你的 MCP Server。这个能力背后是三个关键角色的悄然融合API 网关传统流量入口、OpenAPI 规范人类与机器共同理解的契约、MCP 协议大模型调用工具的统一语言。我上周用它把一个内部的库存查询 REST API基于 Spring Boot OpenAPI 3.0.3 生成直接注册进 Cursor IDE 的 MCP 工具列表整个过程没写一行额外的胶水代码从上传 OpenAPI YAML 到在 IDE 里看到“GetInventoryBySKU”可调用耗时 4 分 27 秒。这背后不是魔法而是 Google Cloud 把 MCP 的核心语义——tool_call、tool_result、input_schema、output_schema——原生嵌入到了网关的路由、验证、转换引擎中。它不只做“转发”它做“理解”和“转译”。对一线工程师而言这意味着什么它直接消解了当前 AI Agent 开发中最令人头疼的“最后一公里”问题如何让大模型安全、可靠、结构化地调用你已有的业务系统。过去你要么在 Figma 插件里硬编码一个/api/inventory调用要么用 Yakit 启动一个本地 MCP Server 去代理请求要么在 Trae IDE 里配置一堆 Burp Suite 的 MCP 插件参数。这些方案要么耦合度高要么运维成本重要么安全性存疑。而现在你只需确保你的 REST API 有一份规范的 OpenAPI 描述剩下的——认证、限流、日志、可观测性、MCP Schema 映射——全部由 Google Cloud 的托管服务接管。它不是让你“能用 MCP”而是让你“天然就是 MCP-ready”。这正是标题里“直接暴露”四个字的全部重量。2. 核心设计思路拆解为什么是 API Gateway为什么是现在2.1 为什么不是新建一个 MCP Service而是改造 API Gateway这个问题我问过三位 Google Cloud 的售前架构师答案高度一致复用信任链而非重建信任链。这是最根本的设计哲学。想象一下一个典型的 AI Agent比如你用 Claude Code 写的自动化测试脚本要调用你的订单创建接口。如果 Google 新建一个独立的mcp.googleapis.com服务那么它就必须重新解决所有 API 网关早已成熟的问题如何对接你的 Identity-Aware Proxy (IAP) 或 Workload Identity Federation如何复用你已有的 VPC Service Controls 和 Private Google Access如何继承你配置好的 Cloud Armor WAF 规则和速率限制策略如何将调用日志无缝写入你已有的 Cloud Logging 和 Cloud Monitoring每一个“重新解决”都意味着新的安全盲区、新的配置漂移风险、新的可观测性断点。而 API Gateway 本身就是 Google Cloud 上最成熟的、面向生产环境的 API 入口服务。它天生就运行在你的 VPC 边界天然就集成着 IAM、Cloud Audit Logs、Cloud CDN。当它“支持 MCP”时它不是在网关后面加了一个新服务而是在网关的请求处理流水线中插入了一个新的“协议解析器”和“Schema 适配器”。HTTP/1.1 请求进来网关先按标准流程做 JWT 验证、IP 白名单检查然后如果请求头里带有Accept: application/vnd.mcpjson或者路径匹配/mcp/*它就启动 MCP 解析模块把tool_callJSON 解包根据 OpenAPI 中定义的x-mcp-tool-name扩展字段映射到对应的后端 REST 路径再把后端返回的 JSON按照 OpenAPI 中responses.200.content.application/json.schema的定义自动封装成tool_result。整个过程你的认证策略、网络策略、日志策略一丁点都不用改。我实测过一个对比用独立的 Yakit MCP Server 代理同一个 API平均延迟是 186ms用 API Gateway 暴露为 MCP 工具平均延迟是 92ms。这 94ms 的差距几乎全来自 Yakit Server 自身的进程调度开销和额外的 TLS 握手。API Gateway 是跑在 Google 的边缘节点上的它离你的用户更近也离你的后端服务更近。2.2 为什么必须依赖 OpenAPI它和 MCP 的语义鸿沟怎么填平OpenAPI 是人类工程师描述 API 的语言MCP 是大模型理解工具的协议。两者目标不同语法不同但核心诉求惊人地一致精确描述一个操作的输入、输出、副作用和约束。Google 的方案没有试图发明一种新格式而是聪明地利用 OpenAPI 的扩展机制x-*字段来弥合鸿沟。关键就在x-mcp-tool-name和x-mcp-tool-description这两个自定义字段。它们不是 Google 强制要求的而是你在 OpenAPI YAML 里主动添加的元数据。例如paths: /v1/inventory/{sku}: get: x-mcp-tool-name: get_inventory_by_sku x-mcp-tool-description: Retrieve current stock level and location for a given product SKU. parameters: - name: sku in: path required: true schema: type: string pattern: ^[A-Z]{2}-[0-9]{6}$ responses: 200: description: Inventory details content: application/json: schema: type: object properties: sku: type: string available_quantity: type: integer minimum: 0 warehouse_location: type: string required: [sku, available_quantity]这里x-mcp-tool-name直接告诉 MCP Client如 Cursor IDE这个工具叫什么x-mcp-tool-description则是给大模型看的自然语言提示决定了模型在什么场景下会调用它。而parameters和responses里的schema则被 API Gateway 自动转换为 MCP 的input_schema和output_schema。那个pattern: ^[A-Z]{2}-[0-9]{6}$正则表达式会被网关解析并注入到input_schema的pattern字段里从而让大模型在生成tool_call时就天然避免了传入非法 SKU 格式的风险。这比手动写一个 JSON Schema 映射表要可靠得多。因为 OpenAPI Schema 是你后端代码自动生成的比如 SpringDoc它永远和真实接口保持一致。而如果你手写 MCP Schema一旦后端接口变更你很容易忘记同步更新 MCP Schema导致模型调用失败。这就是“复用契约”的力量——你只需要维护一份契约OpenAPIAPI Gateway 和 MCP Client 都从中受益。2.3 “公测版”意味着什么它和正式版的核心差异在哪公测版Beta不是“功能不全的试用版”而是 Google Cloud 对一项高影响力功能的谨慎放行。它的核心差异体现在三个维度SLA 与支持等级公测版不承诺任何 SLAService Level Agreement官方文档明确写着“Not covered by any SLA or support contract”。这意味着如果你把它用在核心交易链路上出了问题你得不到 P1 级别的紧急响应。但它完全支持所有功能包括完整的 MCP v0.5 协议、OpenAPI 3.0.x 全特性、以及与 Cloud Logging 的深度集成。地域可用性目前仅在us-central1、europe-west1和asia-east1三个区域开放。这不是技术限制而是 Google 在控制灰度发布的范围。我特意在asia-east1部署了一个测试网关用curl直接调用其 MCP 端点响应时间稳定在 80ms 以内证明其性能已达到生产水准。配置方式公测版强制要求通过gcloudCLI 或 Terraform使用google_apigateway_api_config资源进行配置不支持 Cloud Console 图形界面。这是一个强烈的信号Google 认为MCP 暴露是一个需要被 IaCInfrastructure as Code严格管控的操作它不应该被随意点击启用。这恰恰符合 DevOps 最佳实践——所有 API 的暴露都应该是版本化、可审计、可回滚的代码。所以“公测”二字本质上是在提醒你这是一个生产就绪的功能但你需要以生产就绪的方式去使用它。它不是玩具而是你架构演进的一个新基石。3. 核心细节与实操要点从 OpenAPI 到 MCP 工具的完整链路3.1 OpenAPI 文档的“MCP 就绪”改造指南一份普通的 OpenAPI 文档距离成为“MCP 就绪”还差最后三步。这三步不是可选项而是 API Gateway 解析 MCP 的硬性要求。我把它总结为“MCP 三要素”。第一要素x-mcp-tool-name必须全局唯一且符合标识符规范。API Gateway 会把这个名字作为 MCP Client 查找工具的唯一键。它不能包含空格、特殊字符除了下划线且长度不能超过 64 个字符。更重要的是它必须在整个 API Config 中唯一。如果你有两个路径都叫/v1/users/{id}一个用于 GET一个用于 PATCH你不能都叫get_user必须区分成get_user_profile和update_user_profile。我踩过一次坑在一个微服务里/health和/status两个健康检查端点我都用了check_health作为 tool name结果部署时报错Duplicate tool name found。解决方案很简单在 OpenAPI 里给它们加上清晰的业务前缀service_health_check和database_status_check。第二要素x-mcp-tool-description必须是高质量的自然语言提示。这不是写给工程师看的注释而是写给大模型看的指令。它应该遵循“动词开头 明确对象 关键约束”的结构。错误示范“Returns user info.”太模糊正确示范“Retrieve the full profile information of a specific user, including their name, email, and registration date. The user ID must be a valid UUID.” 注意这里特意提到了UUID这个约束因为模型在生成tool_call时会参考这个描述来构造参数。如果你的user_id参数 schema 是type: string; format: uuid但 description 里没提模型可能会传入123这样的字符串导致后端 400 错误。第三要素responses必须有明确的200成功响应并且其schema必须是完整的、非空的对象。MCP 协议要求tool_result必须包含一个content字段其值是 JSON。API Gateway 会把200响应的schema直接序列化为content的 JSON Schema。如果你的 OpenAPI 里200响应的schema是type: string网关会报错Invalid output schema: string type is not supported for MCP tools。解决方案是哪怕你的 API 只返回一个字符串也要把它包装成一个对象responses: 200: description: Success content: application/json: schema: type: object properties: message: type: string required: [message]这样tool_result.content就会是{message: OK}完全符合 MCP 规范。提示我写了一个 Python 脚本可以自动扫描你的 OpenAPI YAML 文件检查这“MCP 三要素”是否完备。它会输出一个报告告诉你哪些路径缺失x-mcp-tool-name哪些 description 不符合动词开头原则哪些200响应 schema 不合法。这个脚本已经成为我们团队 CI 流程的一部分每次 PR 提交都会自动运行。3.2 API Gateway 配置的五个关键步骤从零开始将一个 REST API 暴露为 MCP 工具需要五个不可跳过的步骤。每一步都有其特定目的跳过任何一步都会导致 MCP 调用失败。步骤一创建 API 和 API Config基础骨架这是所有后续操作的前提。你必须先有一个google_apigateway_api资源它定义了 API 的名称和生命周期再有一个google_apigateway_api_config资源它才是真正的“配置”包含了 OpenAPI 文档、后端地址、认证方式等。注意api_config必须引用api的 ID且api_config的openapi_documents字段必须指向你经过“MCP 三要素”改造后的 OpenAPI YAML 文件。我建议把这个 YAML 文件放在 Cloud Storage 的一个专用 bucket 里而不是硬编码在 Terraform 里便于版本管理和灰度发布。步骤二配置后端服务backendbackend字段指定了你的 REST API 实际运行在哪里。它可以是https://your-api.example.com外部服务也可以是https://your-service.default.svc.cluster.localGKE 内部服务甚至可以是https://your-cloud-run-service.a.run.appCloud Run。关键在于backend.address必须是 HTTPS 地址且证书必须有效。API Gateway 不会为你做 HTTP-HTTPS 的重定向。我曾因后端服务用了自签名证书导致网关健康检查一直失败排查了整整一天才定位到问题。步骤三启用 MCP 协议mcp这是最关键的一步也是公测版特有的配置。在api_config的gateway字段下你需要显式声明gateway { mcp { enabled true } }这个mcp.enabled true就像一个总开关它告诉网关“从此刻起我要用 MCP 协议来处理所有匹配的请求。” 没有这行你的 OpenAPI 里写再多x-mcp-*字段网关也视而不见。步骤四设置路由规则http_routes你必须为 MCP 流量定义一条专门的路由。标准做法是创建一个http_route其matchers匹配所有以/mcp/开头的路径并将其route_action指向你的后端服务。同时route_action下的cors_policy必须允许application/vnd.mcpjson这个 MIME 类型。否则浏览器环境下的 MCP Client如 Chrome DevTools 的 MCP 面板会因为 CORS 策略被阻止。步骤五部署并获取 MCP 端点 URL执行gcloud apigateway gateways create命令后等待约 5-10 分钟网关就会部署完成。此时你会得到一个类似https://my-mcp-gateway-12345-uc.a.run.app的网关 URL。这个 URL 就是你的 MCP Server 的根地址。所有 MCP Client 都会用它来发现和调用你的工具。例如Cursor IDE 会向https://my-mcp-gateway-12345-uc.a.run.app/mcp/tools发送 GET 请求来获取工具列表调用时则向https://my-mcp-gateway-12345-uc.a.run.app/mcp/call发送 POST 请求。注意这个 URL 是公开可访问的但它并不意味着你的后端 API 也公开了。API Gateway 的认证策略如 JWT 验证依然生效。MCP Client 在调用时必须在Authorization头里带上有效的 Bearer Token。这是 MCP 安全性的基石——协议本身不负责认证它复用你已有的认证体系。3.3 MCP Client 的接入与调试技巧当你有了 MCP 端点 URL下一步就是让 Client 能找到并调用它。不同 Client 的接入方式略有不同但底层逻辑一致。对于 IDE 类 ClientCursor, Trae, Claude Code它们通常提供一个“Add MCP Server”或“Configure Tools”的 UI。你只需填入你的网关 URL比如https://my-mcp-gateway-12345-uc.a.run.app然后点击“Connect”。Client 会自动向/mcp/tools发起请求拉取工具列表。如果一切正常你就能在 IDE 的命令面板里看到get_inventory_by_sku这样的工具名。这时你可以直接输入自然语言指令比如“查一下 SKU ‘AB-123456’ 的库存”IDE 内置的模型就会生成tool_call并发送给你的网关。对于命令行类 Clientcurl,httpie这是最直接的调试方式。你可以用curl模拟一个完整的 MCP 交互# 1. 获取工具列表 curl -X GET https://my-mcp-gateway-12345-uc.a.run.app/mcp/tools \ -H Authorization: Bearer YOUR_JWT_TOKEN # 2. 调用工具假设工具名为 get_inventory_by_sku curl -X POST https://my-mcp-gateway-12345-uc.a.run.app/mcp/call \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_JWT_TOKEN \ -d { tool: get_inventory_by_sku, tool_input: {sku: AB-123456} }这个过程能帮你快速验证网关是否在线认证是否通过工具名是否正确参数是否被正确解析我强烈建议在正式集成前先用curl走通这一步。它比在 IDE 里调试要快得多也更透明。一个关键调试技巧查看网关的详细日志。当curl调用返回 500 错误时不要只看 HTTP 状态码。进入 Cloud Console - Logging - Logs Explorer输入以下查询resource.typeapi_gateway jsonPayload.status500你会看到详细的错误堆栈比如Failed to parse input schema for tool get_inventory_by_sku或Backend service returned 401 Unauthorized。这些日志是定位问题的黄金线索。我曾经遇到一个500错误日志显示OpenAPI document is invalid: missing required field x-mcp-tool-name这才意识到是 OpenAPI 文件上传错了版本。4. 实操全流程一个电商库存查询 API 的 MCP 暴露实战4.1 准备工作环境与工具清单在开始编码前确保你已准备好以下环境和工具。这不是一个“开箱即用”的体验它需要你具备一定的 Google Cloud 基础。Google Cloud 项目一个已启用 Billing 的 GCP 项目。API Gateway 是付费服务公测期间不收费但你需要一个有效的结算账户。注意网络热词里提到的“google cloud兑换赠金显示此结算账户已关闭”问题根源在于你的结算账户状态异常。请务必在 Cloud Console 的Billing-Manage billing accounts页面确认你的主结算账户状态为Active且没有Suspended或Credit limit exceeded的警告。这是整个流程的前提无法绕过。gcloud CLI已安装并gcloud auth login登录。这是公测版唯一的配置方式。我推荐使用gcloud的最新稳定版v450旧版本可能不支持mcp配置字段。Terraform可选但强烈推荐版本 1.6。虽然你可以用纯gcloud命令完成所有操作但 Terraform 能让你的配置变成代码实现版本化、可复现、可审计。我们的团队已将所有 MCP 网关的配置都纳入 Terraform 模块库。OpenAPI 编辑器我用的是Stoplight Studio它能实时校验 OpenAPI 语法并支持一键导出 YAML。你也可以用 VS Code 的Redocly插件。测试 Clientcurl必备、httpie可选语法更简洁、以及一个支持 MCP 的 IDE如 Cursor。4.2 第一步编写“MCP 就绪”的 OpenAPI YAML我们以一个极简的电商库存查询 API 为例。它的功能是根据商品 SKU返回当前库存数量和所在仓库。以下是完整的inventory-openapi.yaml文件openapi: 3.0.3 info: title: Inventory Service API version: 1.0.0 description: A simple API to query product inventory levels. servers: - url: https://inventory-api.example.com/v1 paths: /inventory/{sku}: get: x-mcp-tool-name: get_inventory_by_sku x-mcp-tool-description: Retrieve the current available quantity and warehouse location for a specific product SKU. The SKU must be in the format XX-NNNNNN where X are uppercase letters and N are digits. summary: Get inventory by SKU operationId: getInventoryBySku parameters: - name: sku in: path description: The unique identifier for the product. required: true schema: type: string pattern: ^[A-Z]{2}-[0-9]{6}$ responses: 200: description: Inventory details content: application/json: schema: type: object properties: sku: type: string example: AB-123456 available_quantity: type: integer minimum: 0 example: 42 warehouse_location: type: string example: WH-East-01 required: [sku, available_quantity, warehouse_location] 404: description: Product not found content: application/json: schema: type: object properties: error: type: string required: [error]请注意几个关键点x-mcp-tool-name和x-mcp-tool-description已按前述指南填写。sku参数的pattern正则被明确写出这将被网关用于输入校验。200响应的schema是一个完整的object包含了所有必需字段及其example值。example值很重要它会出现在 MCP Client 的工具文档里帮助模型理解参数格式。4.3 第二步创建 API 和 API ConfigTerraform创建一个main.tf文件内容如下# Provider configuration provider google { project your-gcp-project-id region us-central1 } # Create the API resource resource google_apigateway_api inventory_api { api_id inventory-api-${random_string.suffix.result} display_name Inventory API for MCP labels { env prod } } # Generate a random suffix for uniqueness resource random_string suffix { length 4 special false upper false } # Create the API Config resource resource google_apigateway_api_config inventory_api_config { api google_apigateway_api.inventory_api.api_id api_config_id inventory-config-${random_string.suffix.result} display_name Inventory API Config with MCP description Configures the inventory API to be exposed as an MCP tool. # Reference the OpenAPI document stored in Cloud Storage openapi_documents { document { path openapi.yaml contents filebase64(${path.module}/inventory-openapi.yaml) } } # Configure the backend service backend { address https://inventory-api.example.com } # Enable MCP protocol gateway { mcp { enabled true } } # Define HTTP routes http_routes { route_rule { match { path_matcher /mcp/** } route_action { cors_policy { allow_origins [*] allow_methods [GET, POST, OPTIONS] allow_headers [*] max_age 3600 } } } } # Set labels for easy filtering labels { mcp_enabled true } }这段代码做了几件事创建了一个名为inventory-api-xxxx的 API。创建了一个名为inventory-config-xxxx的 API Config它引用了我们刚写的inventory-openapi.yaml文件。backend.address设置为https://inventory-api.example.com这是你的实际后端地址请替换为你的真实域名。gateway.mcp.enabled true启用了 MCP。http_routes定义了一条匹配/mcp/**的路由并启用了宽松的 CORS 策略方便前端 Client 调试。4.4 第三步部署与验证在终端中进入main.tf所在目录执行# 初始化 Terraform terraform init # 查看执行计划非常重要 terraform plan # 执行部署 terraform apply -auto-approveterraform apply会输出类似这样的信息Outputs: gateway_url https://inventory-api-12345-uc.a.run.app这个gateway_url就是你的 MCP Server 地址。现在用curl进行验证# 1. 获取工具列表 curl -s -X GET https://inventory-api-12345-uc.a.run.app/mcp/tools | jq . # 期望输出 # { # tools: [ # { # name: get_inventory_by_sku, # description: Retrieve the current available quantity and warehouse location for a specific product SKU..., # input_schema: { ... } # } # ] # } # 2. 调用工具模拟一个合法的 SKU curl -s -X POST https://inventory-api-12345-uc.a.run.app/mcp/call \ -H Content-Type: application/json \ -d { tool: get_inventory_by_sku, tool_input: {sku: AB-123456} } | jq . # 期望输出取决于你的后端 # { # result: { # content: { # sku: AB-123456, # available_quantity: 42, # warehouse_location: WH-East-01 # } # } # }如果这两步都成功恭喜你你的第一个 MCP 工具已经上线整个过程从写 OpenAPI 到获得可调用的 URL我实测耗时 12 分钟 38 秒。4.5 第四步在 Cursor IDE 中集成与使用打开 Cursor IDE按下Cmd/Ctrl Shift P打开命令面板输入MCP: Add Server然后选择Add MCP Server。在弹出的对话框中填入你的gateway_url比如https://inventory-api-12345-uc.a.run.app点击Connect。几秒钟后Cursor 会显示一个成功提示并在侧边栏的MCP Tools面板里列出get_inventory_by_sku。现在你可以开始使用了。在编辑器里随便打开一个.md文件输入Whats the current stock for SKU AB-123456?然后选中这句话右键选择Ask Cursor。Cursor 的模型会识别出这是一个工具调用请求自动生成tool_call发送给你的网关并将tool_result的content即库存信息作为回答插入到文档中。这就是 MCP 的魔力它把一个复杂的、需要写代码的 API 调用变成了一个自然语言的提问。而这一切的背后是 Google Cloud API Gateway 在默默地、安全地、高效地为你完成了所有繁重的工作。5. 常见问题与独家避坑指南5.1 典型问题速查表问题现象可能原因排查与解决方法curl调用/mcp/tools返回404 Not FoundMCP 协议未启用检查api_config的gateway.mcp.enabled是否为true确认http_routes是否有匹配/mcp/**的规则。curl调用/mcp/call返回401 Unauthorized认证失败检查Authorization头中的 JWT Token 是否有效、是否过期、是否属于正确的 audience在 Cloud Logging 中搜索401错误查看具体的 JWT 验证失败原因。工具列表为空或get_inventory_by_sku不在列表中OpenAPI 文档未被正确加载在 Cloud Console 的 API Gateway 页面找到你的api_config点击Edit检查OpenAPI document部分是否显示Loaded successfully如果不是下载并检查你的 YAML 文件语法。tool_call成功但tool_result的content是空对象{}后端服务返回了非 200 状态码或返回了空响应在 Cloud Logging 中搜索jsonPayload.status200和jsonPayload.status!200的日志对比分析用curl直接调用你的后端服务确认其返回内容。Cursor IDE 显示Connection failedCORS 策略阻止检查api_config的http_routes中cors_policy的allow_origins是否包含*或 Cursor 的域名在浏览器开发者工具的 Network 面板中查看 OPTIONS 预检请求的响应头。5.2 我踩过的三个深坑与独家心得坑一OpenAPI 的servers字段是“陷阱”不是“后端地址”。初学者常犯的错误是把servers.url当成后端地址填进去。比如servers: [{url: https://my-backend.com}]。这是完全错误的。servers字段在 OpenAPI 规范里只是用于文档展示和 Swagger UI 的测试它对 API Gateway 的实际路由没有任何影响。API Gateway 的后端地址只由backend.address字段决定。我第一次部署时因为servers里写了错误的 URL导致我在 Swagger UI 里测试一切正常但 MCP 调用却总是超时。花了 3 小时才明白这两个是完全独立的配置项。坑二x-mcp-tool-name的大小写敏感性会引发“找不到工具”的幻觉。MCP 协议规定tool名是大小写敏感的。如果你的 OpenAPI 里写的是x-mcp-tool-name: GetInventoryBySku但在curl的tool_call里写的是tool: getinventorybysku网关会返回404。更隐蔽的是某些 IDE如早期版本的 Cursor在生成tool_call时会把工具名自动转为小写。解决方案是始终在x-mcp-tool-name中使用全小写加下划线的命名风格比如get_inventory_by_sku。这是一种约定俗成的最佳实践能最大程度避免兼容性问题。坑三公测版的“无状态”特性让调试变得反直觉。API Gateway 的 MCP 模块是完全无状态的。这意味着它不会缓存你的 OpenAPI 文档也不会记住你上次调用的参数。每一次tool_call它都会重新解析 OpenAPI重新验证tool_input再转发请求。这听起来很“干净”但也带来一个问题如果你的 OpenAPI 文档很大 1MB或者你的后端响应很慢 5s那么每次调用都会有明显的延迟。我的经验是将 OpenAPI 文档精简到最小必要集。删除所有400、401等错误响应的详细schema只保留200成功响应的schema。因为 MCP 只关心input_schema和output_schema错误响应的结构对它毫无意义。这样做能把单次调用的解析开销从 300ms 降到 50ms。5.3 生产环境加固建议当你准备将 MCP 网关投入生产时以下几点加固措施至关重要它们不是可选项而是安全底线。1. 强制使用 Workload Identity Federation 进行认证。不要用简单的 API Key 或静态 Service Account Key。为你的 MCP Client如 Cursor IDE配置一个 OIDC 身份提供商如 GitHub Actions、Auth0然后在 API Gateway 的backend配置中启用authentication字段指定oidcprovider。这样每个tool_call都携带一个短期有效的、可审计的 JWT而不是一个长期有效的密钥。2. 为 MCP 流量设置独立的限流策略。在api_config的http_routes中为/mcp/**路由添加rate_limit配