Picture this ticket. Somebody’s shiny new assistant “finds a way” to reset a user’s MFA, and if you traced it back, you might find it went through something like /internal/v2/admin/resetFactor, an endpoint documented in one wiki page from 2021 and a Slack thread nobody can find. In that scenario, the assistant wouldn’t have hacked anything. It would have read a description, decided the endpoint was a skill it had, and used it. That’s the scenario I kept imagining while reading about the new Google Cloud API Gateway MCP tools for REST APIs, which let a gateway you already run hand your API operations to AI agents as callable tools.
The feature is useful, and the fine print matters more than the headline. Let’s go through what Google actually shipped and which doors it opens.
What Google Actually Announced
On September 24, Google’s developer blog published Turn your REST APIs into MCP tools with Google Cloud API Gateway. The short version: in Public Preview, API Gateway can now act as a remote Model Context Protocol (MCP) server. You annotate the OpenAPI spec you already deploy, redeploy, and the gateway starts serving MCP on a /mcp path. Agents built with frameworks like Google’s Agent Development Kit can then discover your operations and call them. You don’t have to build or host a separate MCP server.
A few specifics worth pinning down:
- It’s a preview, not GA. The MCP overview in Google’s documentation marks the feature as subject to the Pre-GA Offerings Terms, available “as is” with possibly limited support. The API Gateway release notes list it as a Public Preview feature dated September 11, about two weeks before the blog post.
- It’s opt-in. Nothing happens to your APIs until you add the x-google-api-management MCP setting to your spec. Google didn’t flip a switch on anybody’s endpoints.
- OpenAPI 3.x only. Specs still on OpenAPI 2.0 aren’t supported, so some shops will have a migration to do first.
- Tools only. The gateway supports initialize, tools/list and tools/call. MCP resources and prompts aren’t supported, and neither are stdio transport or streaming and long-running calls. Google says resources, prompts, response streaming and Model Armor payload inspection are on the roadmap.
- Some limits. Operations that return empty bodies, like HTTP 204, aren’t exposed. A gateway serves up to 1,000 tools. MCP and model routing can’t be enabled in the same API config.
So the accurate version of the hot take is narrower: if you run Google Cloud API Gateway and choose to turn this on, your REST operations can become agent tools with a few lines of YAML. That’s still a big deal. It just isn’t every endpoint on the internet.
How Google Cloud API Gateway MCP Tools for REST APIs Handle Auth
This is the part I actually care about, and Google’s design is mostly sensible. According to the blog, the gateway transcodes each tool call into the matching REST request, and it’s “indistinguishable from a normal REST call.” That means the JWT or API key checks, quotas and logging you already configured still apply, and MCP and REST traffic share one policy path.
The configuration guide lays out the authentication model by method:
- initialize and the handshake acknowledgment are unauthenticated.
- tools/call reuses whatever authentication the underlying operation requires. If the REST endpoint wants a JWT, so does the tool.
- tools/list, the method that tells a client what tools exist, is unauthenticated by default. Google strongly recommends locking it down, and if you do, it has to be a JWT scheme. API keys aren’t supported for discovery in the preview.
Google’s own blog says the quiet part plainly: an open tools/list “publishes your tool names and input schemas to anyone who asks.” Tool names and schemas are a map. Even if every call is authenticated, you’ve handed out a labeled floor plan of the building.
The Global Toggle Is the Real Door
Here’s where the “every endpoint” worry has some truth to it. You can enable MCP two ways. Per operation, you mark the specific paths you want exposed. Globally, with mcp: true, the docs say all eligible operations are exposed as tools. Eligible means GET, POST, PUT, PATCH and DELETE. By default the tool name is the operationId and the description comes from the operation’s description or summary.
One gotcha deserves bold type. Configuring the mcp setting as an object, which is how you secure tools/list, also enables MCP globally. Google’s blog flags it right in a code comment. So the admin who does the responsible thing and requires a JWT for discovery has also, without trying, published every eligible operation in the spec. You then opt individual operations back out with x-google-mcp-tool: false. That’s default-open behavior hiding inside a security setting, and it’s exactly how the half-documented admin endpoint ends up in an agent’s toolbox.
The docs’ own example is a DELETE operation described as “Permanently delete a shelf and every book on it.” Sure, it’s a bookstore demo. But swap “shelf” for “tenant” and you have the ticket I opened with.
Descriptions Are Now Security Controls
Google notes that a tool’s description “is the primary signal an LLM uses to decide when to call it.” That changes the job of your OpenAPI summaries. For years, “Deletes stuff (internal, do not use)” was a note for humans. An agent may read that as a capability with a mild warning. If an operation shouldn’t be called by an agent, don’t rely on the description to say so. Keep it out of the tool list.
What I Would Do Before Turning It On
- Audit the spec first. Every operation in that OpenAPI file is a candidate tool. Find the leftovers: admin routes, debug endpoints, anything “temporary.”
- Prefer per-operation opt-in over global. If you must use the object form to secure discovery, add explicit opt-outs and review the resulting tools/list output.
- Require a JWT on tools/list in anything that isn’t a sandbox. Unauthenticated discovery is fine for a demo and a gift for recon.
- Separate agent credentials from human ones. Since the backend can’t tell MCP calls from REST calls, give agents their own identities so the logs can.
- Treat destructive methods as their own review. PUT, PATCH and DELETE exposed to an agent deserve the same scrutiny as handing a junior admin the keys.
I like this feature. Rebuilding auth and quota logic in a separate MCP server was always going to produce worse security than the gateway you already hardened. But convenience moves the risk to your spec file. The gateway will faithfully publish what you describe, so make sure you’re describing only the doors you meant to install.