Google Cloud API Gateway Adds Native Model Context Protocol Support
A Public Preview release allows development teams to convert existing REST services into AI agent tools using OpenAPI annotations.
Key takeaways
- Google Cloud API Gateway can now function as a remote Model Context Protocol (MCP) server in Public Preview.
- Developers can expose REST APIs as MCP tools by annotating existing OpenAPI 3.x specifications without writing separate proxy servers.
- Discovery endpoints via tools/list are unauthenticated by default, requiring teams to manually configure JWT authentication for production security.
- The preview currently excludes stdio transport, OpenAPI 2.0, HTTP 204 empty responses, and concurrent Model Routing configurations.
On September 24, 2026, Google introduced a Public Preview feature enabling Google Cloud API Gateway to operate natively as a remote Model Context Protocol (MCP) server. The update allows software teams to expose existing REST backends to artificial intelligence agents without developing, hosting, or maintaining separate middleware servers to bridge the protocols. By converting JSON-RPC requests directly into standard REST calls, the gateway bridges enterprise infrastructure with agentic frameworks such as the Agent Development Kit (ADK) and Gemini Enterprise.
Previously, exposing private application programming interfaces to AI models required running dedicated MCP servers that duplicated routing, authentication, logging, and rate-limiting logic. Under the new implementation, the gateway handles protocol transcoding directly on an HTTP endpoint, ensuring that AI-driven agent traffic and normal HTTP clients share a single policy path.
How Google Cloud API Gateway Serves MCP Tools
To turn existing endpoints into agent tools, developers annotate an OpenAPI 3.0.x or 3.1.x document using Google-specific vendor extensions. Enabling the feature requires setting x-google-api-management.mcp: true at the document root, according to the Google Cloud documentation. Individual endpoints can then be customized, renamed, or excluded using the x-google-mcp-tool directive.
Once the configuration is deployed, the gateway begins serving MCP communications on the /mcp base path. When an AI client invokes an operation, the gateway accepts the incoming MCP JSON-RPC payload, validates any supplied credentials, and inspects the payload. It translates the tools/call message into an equivalent HTTP REST request targeting the backend service—such as an application running on Cloud Run. When the backend responds, the gateway packages the result back into standard MCP JSON-RPC format for the client.
Because the backend only sees standard REST calls, internal microservices do not require code changes or new software libraries. Furthermore, invoking a tool against an operation consumes the exact same quota allocation configured for direct REST traffic.
Catalog Integration and the Security Discovery Boundary
For enterprise tool governance, gateways configured with MCP automatically publish metadata to Google Cloud API hub and register within Agent Registry, according to Google's announcement. This registration allows autonomous agents and developer tooling to discover operational schemas across cloud projects once the agentregistry.googleapis.com service is enabled.
However, the rollout introduces an important architectural consideration regarding default discovery permissions. While the tools/call execution method strictly enforces whatever authentication (such as API keys or JSON Web Tokens) the underlying REST operation requires, the tools/list discovery endpoint is unauthenticated by default. If published without additional rules, anyone who queries the gateway endpoint can inspect available tool names, descriptions, and input parameters, as analyzed by Learnetto.
To safeguard sensitive system architecture before moving workloads into production, Google advises teams to enforce JSON Web Token (JWT) authentication explicitly under the x-google-api-management.mcp.tools-list.security property. The company notes that standard API keys cannot be used to secure the tools/list discovery method.
Public Preview Limitations and Architecture Scope
The feature is currently scoped to remote HTTP servers and OpenAPI 3 specifications, leaving several protocol capabilities unsupported during the Public Preview. As detailed by daily.dev and Google Cloud documentation, the gateway enforces the following boundaries:
- Transport and specs: Only remote HTTP POST communication is supported; local stdio transport is omitted. Legacy OpenAPI 2.0 definitions cannot be parsed.
- Protocol primitives: The gateway only handles lifecycle handshakes (
initialize,notifications/initialized) alongside tool operations (tools/list,tools/call). Protocol prompts (prompts/*) and resources (resources/*) are not supported. - Operational limits: A single gateway configuration supports a maximum of 1,000 tools. Backends returning empty bodies (such as HTTP 204 No Content status codes) are not exposed, and deeply nested schemas may not fully resolve in discovery responses.
- Feature mutual exclusion: Organizations cannot enable both native MCP and Model Routing within the same API configuration document.
- Streaming: Response streaming and long-running tool executions are not supported in the initial preview.
Google indicated that response streaming, Model Armor payload inspection, and MCP prompts and resources are planned on the product roadmap. For advanced enterprise monetization, complex lifecycle policies, or custom traffic governance, Google recommends Apigee, while outbound agent requests can be governed using Agent Gateway.
Frequently asked questions
What versions of OpenAPI are required to use MCP on Google Cloud API Gateway?
The feature requires OpenAPI 3.0.x or OpenAPI 3.1.x specifications. OpenAPI 2.0 is not supported, meaning older definitions must be upgraded first.
How is tool discovery secured on the gateway?
By default, tool discovery via tools/list is unauthenticated. To secure tool discovery in production, developers must configure JWT authentication in the specification, as API keys cannot secure the tools/list endpoint.
Can I use Model Routing and MCP in the same API Gateway configuration?
No. Google Cloud enforces mutual exclusion between MCP and Model Routing within the same API configuration document. Enabling x-google-api-management.mcp prevents the use of x-google-model-router.
Sources
- Turn your REST APIs into MCP tools with Google Cloud API Gatewaydevelopers.googleblog.com · Sep 24, 2026 · Official
- Model Context Protocol overviewGoogle Cloud Documentation
- Google Cloud API Gateway can now turn existing REST operations into MCP toolsLearnetto · Sep 24, 2026
- Turn your REST APIs into MCP tools with Google Cloud API Gatewaydaily.dev · Sep 24, 2026
- API Gateway MCP de Google: qué es y cómo usarlo hoyCursos inteligencia artificial IA University · Sep 24, 2026
- "IT News" | Just add a few lines to your existing API to turn it into an AI agent tool—Google Cloud API Gateway now supports MCPnote（ノート） · Sep 25, 2026
How this story was made: the newsroom picked it up from developers.googleblog.com, gathered the full text of the sources above, and drafted it with AI assistance. Every factual claim was then checked against those sources before publishing (23 claims checked). Illustrations marked as AI-generated are not photographs. Spotted an error? Tell us.
Published September 27, 2026 at 07:40 UTC
