Google Cloud API Gateway Now Exposes REST APIs as Agent-Ready MCP Tools

Enterprise systems often hide core capabilities behind REST APIs that AI agents cannot access directly. Until now, teams wanting to make those APIs agent-callable had to build and maintain a separate Model Context Protocol (MCP) server alongside their existing gateway infrastructure, duplicating authentication, routing, and quota logic. Google Cloud is closing that gap with an MCP server capability baked into API Gateway.

The Problem It Solves#

Most enterprise data and operations live behind REST services. The Model Context Protocol has emerged as the standard interface through which agents discover and invoke tools—frameworks like Google's Agent Development Kit and Gemini Enterprise understand it natively. But getting a REST API to speak MCP typically required standing up and running an additional server, creating operational overhead and keeping two separate implementations in sync.

How It Works#

In public preview now, Google Cloud API Gateway can act as an MCP endpoint. The process is straightforward:

• Annotate your spec: Add x-google-api-management.mcp: true to your OpenAPI 3.0.x or 3.1.x document, then optionally customize individual operations with x-google-mcp-tool blocks.
• Deploy as usual: Push the updated config to API Gateway. The service automatically generates an MCP-aware configuration and starts serving MCP clients at a /mcp base path—no extra infrastructure needed.
• Connect your agent: Point your MCP client (such as an ADK agent) to the gateway's /mcp endpoint, passing the same credentials your REST operations already expect.

API Gateway transcodes incoming MCP JSON-RPC tools/call requests into the corresponding REST operations, applies your existing policies (authentication, quotas, logging), and translates responses back into MCP format. Because the transcoded request is indistinguishable from a normal REST call, your JWT or API-key security, rate limiting, and audit trails all remain active and unchanged—MCP and REST traffic share one policy path and draw from the same quota allocations.

Key Considerations#

For tool discovery—the tools/list method—you can choose whether to require authentication. By default it is open, which speeds up development but exposes your tool names and schemas to anyone. Production deployments should require a JWT token. The actual tool invocation () always enforces whatever authentication the underlying REST operation requires, regardless of discovery settings.