Google Cloud can now turn selected REST operations into tools an AI agent can discover and call. That removes the need for a separate MCP server in some deployments, but you still need to decide which operations to expose, who can list them, and what each call can do.
What launched, and what remains in preview?
On September 24, 2026, Google announced support for Model Context Protocol in API Gateway. In public preview, an API Gateway configuration based on OpenAPI 3.0.x or 3.1.x can expose REST operations as remote MCP tools. A client connects to the gateway’s /mcp path, lists the available tools, and invokes one. The gateway translates the MCP call into the corresponding REST request and returns the backend response.
The important distinction is that Google has added a protocol surface to an existing gateway, not a new permission system for agents. Authentication, quotas, and logging configured for an underlying operation still apply when the agent calls it through MCP. A tool’s description also matters: it tells the model when an operation is appropriate, so vague descriptions can lead to poor selection even when the API itself works.
The discovery permission is easy to overlook, though.
Google says it tools/list is unauthenticated by default. That means a client may be able to retrieve tool names and input schemas even when the underlying REST call requires a credential. To protect discovery, configure JWT authentication for the listing method; Google says API keys cannot be secured. By contrast, tools/call enforces the authentication already required by the corresponding REST operation. Treat discovery and execution as two separate tests.
For example, an order-status lookup may be safe to expose to a support agent with scoped credentials. At the same time, a refund or account-deletion operation deserves a different policy and a human approval point. Restricting tool discovery alone will not make a write-capable backend safe. Our Cloudflare private MCP guide covers the network and identity side of another MCP deployment, and our WebMCP permission guide explores why tool availability must not be confused with user authorization.
A small pilot for an API owner
Start with one read-only operation. Move an OpenAPI 2.0 description to 3.x if needed, add a backend and a meaningful description to the operation, and explicitly decide whether to offer it as a tool. In a test configuration, call tools/list first without a credential and then with the intended identity. Confirm that the list contains only the selected operation. Next, invoke the tool with a permitted and a denied credential, inspect the REST-side log, and verify the shared quota is counted once per request.
Keep a rollback path: remove the MCP opt-in or return to the prior gateway configuration if the agent sees too much metadata, selects the wrong operation, or creates an unexpected load pattern. Document the exact tool name, arguments, backend identity, approval owner, and expected failure response before adding write operations.
Limits that change the design
Google’s preview documentation supports tools, not MCP resources or prompts. It does not support stdio transport, response streaming, or long-running tool calls. OpenAPI 2.0 is unsupported, and MCP cannot coexist with model routing in the same API configuration. Google also notes that HTTP 204 operations are not exposed, deeply nested schemas may be incomplete in discovery, and one gateway can serve up to 1,000 tools. These are implementation constraints, not minor footnotes for teams with large or asynchronous APIs.
The useful change is operational consolidation: one REST gateway can present a narrower agent-facing tool surface while retaining existing call policies. The production decision still depends on an inventory of operations, explicit discovery authentication, low-privilege testing, and whether the preview’s protocol and support limits match the workload. Google’s announcement does not set a general-availability date, a preview service-level commitment, or performance improvements for every API.
