大多数企业级功能都隐藏在代理（agent）无法直接访问的 REST API 背后。要让某个功能今天就能被代理调用，团队通常需要搭建并运维一个独立的 MCP 服务器，重新实现其网关已经处理的路由、身份验证和配额逻辑。模型上下文协议（MCP）已成为代理发现和调用工具的标准方式，而 Agent Development Kit（ADK）和 Gemini Enterprise 等框架原生支持该协议。

Google Cloud API Gateway 现在填补了这一空白。在公共预览阶段，API Gateway 可以充当远程 MCP 服务器：对您已部署的 OpenAPI 规范进行注解，然后部署它，您现有的 REST 操作即可作为面向代理的 MCP 工具使用——无需构建、托管或维护单独的服务器。

API Gateway 是 Google Cloud 网关产品线中的轻量级入口。如果您在 Cloud Run 上有一个服务，并希望快速为其 API 提供安全保护、管理和向代理暴露的能力，这是最快的路径。对于完整的企业级 API 和 MCP 平台——包括生命周期管理、高级流量策略和货币化——请使用 Apigee。要控制您的代理向外调用的内容（包括此类 MCP 服务器），请使用 Agent Gateway。模型路由（Model routing）为出站 LLM 调用提供一个稳定的端点，是与 AI 流量另一个方向相配套的能力。

工作原理

API Gateway 在单一端点上接受标准的 MCP JSON-RPC 请求，将每个 tools/call 转码为相应的 REST 请求，应用您现有的策略，并将响应翻译回来。由于转码后的请求与普通的 REST 调用无法区分，您已为该操作配置的 JWT 或 API 密钥身份验证、配额和日志记录将继续正常工作——MCP 和 REST 流量共享完全相同的策略路径，且给定操作的配额分配无论通过何种方式调用都仅使用一份。

1. 注解您的 OpenAPI 规范。MCP 需要 OpenAPI 3.0.x 或 3.1.x；不支持 OpenAPI 2.0，因此如果您的网关仍在运行 2.0 规范，请先迁移它。在文档级别通过 x-google-api-management.mcp 选择加入，并通过 x-google-mcp-tool 自定义或跳过单个操作。每个暴露的操作都需要一个后端和一个非空的描述。

openapi: 3.0.4
info:
title: Order Service
version: 1.0.0

x-google-api-management:
mcp: true # expose this spec's operations as MCP tools
backends:
orders-backend:
address: https://orders-a1b2c3-uc.a.run.app

paths:
/orders/{orderId}:
get:
operationId: getOrderStatus
description: Returns the current status, carrier, and ETA for an order.
x-google-backend: orders-backend
x-google-mcp-tool:
name: get_order_status
description: "Look up the delivery status and ETA of a customer order.
Use this when the user asks where an order is or when it will arrive."
parameters:
- name: orderId
in: path
required: true
schema:
type: string

工具的描述是 LLM 决定何时调用它的主要信号，因此请写明何时以及为何使用该工具，而不仅仅是它返回什么。

2. 部署网关。像往常一样部署 API 配置。API Gateway 会生成一个感知 MCP 的配置，并开始通过 /mcp 基础路径提供 MCP 服务，无需配置额外的基础设施。

3. 决定谁可以发现您的工具。默认情况下，tools/list 是无认证的，这对开发很方便，但会将您的工具名称和输入模式发布给任何询问者。对于生产环境，请要求 JWT——请注意，API 密钥无法保护此方法：

x-google-api-management:
mcp:
tools-list:
security:
orderServiceJwt: [] # the object form also enables MCP globally

无论是否保护发现功能，tools/call 始终强制执行底层 REST 操作所需的任何身份验证。

4. 连接您的代理。将任何 MCP 客户端指向网关的 /mcp 端点。在 ADK 中，这就是工具集加上您的网关已经期望的凭据：

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams

order_tools = McpToolset(
connection_params=StreamableHTTPConnectionParams(
url="https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp",
headers={"x-api-key": API_KEY},
)
)

agent = Agent(
model="gemini-2.5-flash",
name="order_support_agent",
instruction="Help the user check on their orders.",
tools=[order_tools],
)

Python

网关将工具的参数映射回操作的 REST 路径、查询、正文和标头，通过现有策略运行请求，并将后端的响应作为 MCP 结果返回。要在网络层检查该过程：

curl -X POST "https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp" \
-H "content-type: application/json" \
-H "MCP-Protocol-Version: 2025-11-25" \
-H "x-api-key: $API_KEY" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"get_order_status","arguments":{"orderId":"A-1042"}}}'

Shell

{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text",
"text":"{\"orderId\":\"A-1042\",\"status\":\"IN_TRANSIT\",\"eta\":\"2026-09-24\"}"}],
"isError":false}}

JSON

为什么从网关提供 MCP

可发现性。将网关连接到 API Hub，其 MCP 服务器将在此处发布，并带有 MCP 特定元数据，自动出现在 Agent Registry 中，因此代理和开发人员可以找到它公开的工具。

无需运营新内容。现有的规范、网关、身份验证、配额和日志记录即可完成工作——MCP 和 REST 流量保持一致，因为它们共享一个策略路径。

公共预览版涵盖使用当前身份验证的 REST 和 OpenAPI 3.x 后端。MCP 资源和提示、响应流式传输以及 Model Armor 负载检查在路线图之中。有几个限制值得提前了解：返回空正文的操作（如 HTTP 204）不会公开，深层嵌套的对象模式可能无法在 tools/list 中完全呈现，网关最多支持 1,000 个工具，且 MCP 和模型路由不能在同一个 API 配置中同时启用。请参阅文档以了解当前范围。

开始使用

MCP 支持现已在公共预览版中提供。查看文档，今天就将你的第一个 API 转变为面向代理的工具。

Most enterprise capability sits behind REST APIs that agents cannot see. To make one callable by an agent today, teams typically stand up and operate a separate MCP server that re-implements the routing, authentication, and quota logic their gateway already handles. The Model Context Protocol (MCP) has become the standard way for agents to discover and invoke tools, and frameworks like the Agent Development Kit (ADK) and Gemini Enterprise speak it natively.

Google Cloud API Gateway now closes that gap. In Public Preview, API Gateway can act as a remote MCP server: annotate the OpenAPI spec you already deploy, deploy it, and your existing REST operations are available as agent-ready MCP tools — with no separate server to build, host, or maintain.

API Gateway is the lightweight on-ramp in Google Cloud's gateway lineup. If you have a service on Cloud Run and you want its API secured, managed, and exposed to agents in minutes, this is the fast path. For a full enterprise API and MCP platform — lifecycle management, advanced traffic policies, monetization — use Apigee . To govern what your agents call on the way out, including MCP servers like this one, use Agent Gateway . Model routing , which gives you one stable endpoint for outbound LLM calls, is the companion capability for the other direction of AI traffic.

How it works

API Gateway accepts standard MCP JSON-RPC requests on a single endpoint, transcodes each tools/call into the corresponding REST request, applies your existing policies, and translates the response back. Because the transcoded request is indistinguishable from a normal REST call, the JWT or API-key authentication, quota, and logging you already configured for that operation keep working unchanged — MCP and REST traffic share exactly one policy path, and a given operation draws on one quota allocation however it is invoked.

Annotate your OpenAPI spec. MCP requires OpenAPI 3.0.x or 3.1.x; OpenAPI 2.0 is not supported, so if your gateway still runs a 2.0 spec, migrate it first . Opt in at the document level with x-google-api-management.mcp , and customize or skip individual operations with x-google-mcp-tool . Each exposed operation needs a backend and a non-empty description.

openapi: 3.0.4
info:
title: Order Service
version: 1.0.0

x-google-api-management:
mcp: true # expose this spec's operations as MCP tools
backends:
orders-backend:
address: https://orders-a1b2c3-uc.a.run.app

paths:
/orders/{orderId}:
get:
operationId: getOrderStatus
description: Returns the current status, carrier, and ETA for an order.
x-google-backend: orders-backend
x-google-mcp-tool:
name: get_order_status
description: "Look up the delivery status and ETA of a customer order.
Use this when the user asks where an order is or when it will arrive."
parameters:
- name: orderId
in: path
required: true
schema:
type: string

Plain text

A tool's description is the primary signal an LLM uses to decide when to call it, so write when and why to use the tool, not just what it returns.

2. Deploy the gateway. Deploy the API config as usual. API Gateway generates an MCP-aware configuration and begins serving MCP on the /mcp base path, with no extra infrastructure to provision.

3. Decide who can discover your tools. By default tools/list is unauthenticated, which is convenient for development but publishes your tool names and input schemas to anyone who asks. For production, require a JWT — note that API keys cannot secure this method:

x-google-api-management:
mcp:
tools-list:
security:
orderServiceJwt: [] # the object form also enables MCP globally

Plain text

tools/call always enforces whatever authentication the underlying REST operation requires, whether or not you secure discovery.

4. Connect your agent. Point any MCP client at the gateway's /mcp endpoint. In ADK, that is the toolset plus the credential your gateway already expects:

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams

order_tools = McpToolset(
connection_params=StreamableHTTPConnectionParams(
url="https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp",
headers={"x-api-key": API_KEY},
)
)

agent = Agent(
model="gemini-2.5-flash",
name="order_support_agent",
instruction="Help the user check on their orders.",
tools=[order_tools],
)

Python

The gateway maps the tool's arguments back onto the REST path, query, body, and headers of your operation, runs the request through your existing policies, and returns the backend's response as an MCP result. To inspect that on the wire:

curl -X POST "https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp" \
-H "content-type: application/json" \
-H "MCP-Protocol-Version: 2025-11-25" \
-H "x-api-key: $API_KEY" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"get_order_status","arguments":{"orderId":"A-1042"}}}'

Shell

{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text",
"text":"{\"orderId\":\"A-1042\",\"status\":\"IN_TRANSIT\",\"eta\":\"2026-09-24\"}"}],
"isError":false}}

JSON

Why serve MCP from the gateway

Discoverable. Connect your gateway to API hub and its MCP server is published there with MCP-specific metadata and appears in Agent Registry automatically, so agents and developers can find the tools it exposes.

Nothing new to operate. Your existing spec, gateway, authentication, quotas, and logging do the work — MCP and REST traffic stay consistent because they share one policy path.

The Public Preview covers REST and OpenAPI 3.x backends with your current authentication. MCP resources and prompts, response streaming, and Model Armor payload inspection are on the roadmap. A few limits are worth knowing up front: operations returning empty bodies such as HTTP 204 are not exposed, deeply nested object schemas may not render fully in tools/list , a gateway serves up to 1,000 tools, and MCP and model routing cannot be enabled in the same API config. See the documentation for the current scope.

Get started

MCP support is available now in Public Preview. Check out the documentation and turn your first API into an agent-ready tool today.