Google Cloud API Gateway can now turn existing REST operations into MCP tools

What changed

API Gateway can now derive MCP tools from an OpenAPI 3.x document. A document-level x-google-api-management.mcp setting enables the feature, while x-google-mcp-tool can include, skip, rename, or describe individual operations. Each exposed operation needs a backend and a useful description.

The practical change is where the protocol adapter runs. Teams with an existing Google Cloud gateway no longer need a separate service that repeats API routing, authentication, quota, and logging logic just to speak MCP. Their backend remains a normal REST service.

How the request path works

An MCP client initializes against POST /mcp, requests tools/list, and sends tools/call with a tool name and arguments. API Gateway validates the request, maps those arguments to the OpenAPI path, query, headers, and body, calls the existing backend, and translates the HTTP response into an MCP JSON-RPC result.

The backend cannot distinguish a transcoded MCP request from a direct REST request. That keeps one policy path for REST and agent traffic, but it also means backend monitoring must use the /mcp gateway path or custom metrics when teams need to separate agent activity.

The security boundary to review first

tools/call reuses the API key or JWT rules on the underlying REST operation. tools/list behaves differently: tool discovery is unauthenticated by default. A public tools/list response can reveal tool names and input schemas even when calls remain protected.

Protect tool discovery with JWT before production use. API keys cannot secure tools/list in this preview. Also review each exposed operation for least privilege, destructive effects, tenant isolation, idempotency, rate limits, audit fields, and useful error messages. A generated tool schema does not make a REST operation safe for an agent.

What teams can build

Google's launch example turns an order-status endpoint into get_order_status, allowing an ADK support agent to retrieve carrier and ETA data through MCP. The same pattern can fit bounded read operations such as inventory lookup, shipment tracking, account status, and internal knowledge search when their authorization rules are already correct.

Write tool descriptions around when and why an agent should call an operation. Avoid exposing a large CRUD surface by default. A smaller set of task-shaped tools gives the model fewer ambiguous choices and gives operators a clearer permission and evaluation boundary.

A safer adoption checklist

• Start with one read-only operation and explicitly configure x-google-mcp-tool instead of globally publishing every eligible endpoint.
• Protect tools/list with one configured JWT security scheme, then verify unauthenticated discovery is rejected.
• Test initialize, tools/list, valid calls, invalid arguments, expired credentials, cross-tenant access, rate limits, and backend failures with an MCP client.
• Check that request bodies use the required body wrapper and that tool names and descriptions are clear to the model.
• Compare direct REST and MCP responses, latency, logs, quotas, and error handling before adding write operations.
• Add human confirmation and idempotency controls for destructive or costly actions outside the gateway when the workflow needs them.

Preview limits and open evidence

Streaming and long-running tool calls are not supported. The preview also excludes MCP resources, prompts, stdio transport, OpenAPI 2.0, empty HTTP 204 operations, and some deeply nested schema shapes. MCP and model routing cannot be enabled in the same API config.

Google's announcement and documentation establish the feature and its request behavior. Learnetto did not find an independent production report for this new API Gateway preview by September 26. Treat lower adapter maintenance as a plausible engineering benefit, then measure reliability, latency, discoverability, and agent success on your own operations before expanding access.