Google Cloud put a Public Preview on API Gateway that turns REST operations you already expose through OpenAPI into remote MCP tools. You annotate the OpenAPI spec already deployed on the gateway. After a normal deploy, the gateway serves MCP on the `/mcp` base path. There is no separate MCP server to build, host, or maintain.
That is a REST-to-MCP surface for APIs you already run behind Google Cloud API Gateway. It is not a desktop-agent product, and it is not a proxy in front of other people's MCP servers.
Sources are the Google Developers Blog post Turn your REST APIs into MCP tools with Google Cloud API Gateway (September 24, 2026), the MCP overview and configure MCP docs (last updated October 9, 2026), and the API Gateway release notes for Public Preview on September 11, 2026 and API key auth for `tools/list` on September 30, 2026. All checked on October 12, 2026.
The short answer
Use this when you already have OpenAPI 3.0.x or 3.1.x REST operations on API Gateway and you want agents to call those same operations as MCP tools without standing up a second host. MCP and REST share one policy path for auth, quota, and logging. One quota allocation covers both ways of calling. `tools/call` always enforces whatever auth the underlying REST operation requires. For production, do not leave `tools/list` open: require JWT or API key via `tools-list.security` (current docs; the September 24 blog's "API keys cannot" note is outdated). Preview terms apply. Empty-body responses such as HTTP 204 are not exposed, nested schemas may not fully render in `tools/list`, and the gateway serves up to 1,000 tools.
What it is and how it works
API Gateway acts as a remote MCP server. It proxies MCP JSON-RPC into HTTP REST backends. Supported methods today are `initialize`, `notifications/initialized`, `tools/list`, and `tools/call`. Not supported: `resources/*`, `prompts/*`, stdio transport, OpenAPI 2.0, and streaming or long-running tool calls. OpenAPI 2.0 APIs must migrate to 3.x first.
The gateway transcodes each tool call into a normal REST request. To the backend, that request looks like any other REST call through the gateway. Tool descriptions are the main signal the model uses when deciding whether to call a tool, so write when and why an operation should be used, not only what it does.
Google positions API Gateway as a lightweight on-ramp in its lineup. Apigee is the full enterprise API and MCP platform. Agent Gateway governs outbound agent calls. Model routing is a companion for outbound LLM traffic. MCP and model routing cannot share the same API config.
Annotate OpenAPI and deploy
Opt in with the `x-google-api-management.mcp` extension on the OpenAPI already deployed to the gateway. The object form enables MCP globally; set `x-google-mcp-tool: false` on operations you want to skip. Customize name and description with `x-google-mcp-tool`. Each exposed operation needs a backend and a non-empty description.
Eligible HTTP methods are GET, POST, PUT, PATCH, and DELETE. Tool names must match `[A-Za-z0-9_.-]{1,128}` and stay unique. Path and query parameters map to top-level tool arguments. The request body sits under `body`. Headers can be top-level arguments, but you cannot bind reserved or `x-google-` headers.
Deploy as usual. The canonical MCP path is `/mcp` (or a version-prefixed path). Clients should send the `MCP-Protocol-Version` header after initialize; if it is absent, the gateway falls back to `2025-03-26`. Protocol errors often return HTTP 200 with a JSON-RPC error body, so clients must read the payload rather than fail only on transport status.
Google's materials include an OpenAPI example with `x-google-api-management.mcp: true`, backends, and `x-google-mcp-tool` name and description fields, plus an ADK example that connects with `McpToolset` and `StreamableHTTPConnectionParams` to `/mcp`. When you integrate API hub and Agent Registry, those surfaces can help with discovery.
Auth for list versus call
`initialize` and `notifications/initialized` stay unauthenticated. `tools/call` reuses the auth required by the underlying REST operation. `tools/list` is unauthenticated by default; for production, set `tools-list.security` so listing requires a JWT or an API key. An API key for `tools/list` must arrive in the `x-api-key` header, not as a query parameter. Release notes record API key support for `tools/list` on September 30, 2026. Prefer the October 9 docs over the September 24 blog where they disagree on API keys.
Preview limits and roadmap
This is Pre-GA / Public Preview. Current coverage is REST plus OpenAPI 3.x with the auth model above. Google lists a roadmap for MCP resources and prompts, response streaming, and Model Armor payload inspection. Hard limits to plan around:
- Empty-body operations (for example HTTP 204) are not exposed as tools.
- Deeply nested schemas may not fully render in `tools/list`.
- Up to 1,000 tools per gateway.
- MCP and model routing cannot be enabled in the same API config.
Fitting it beside a self-hosted agent
Google documents ADK and Streamable HTTP to `/mcp`. It does not list OpenClaw, Hermes, or Grok Bot, and this post does not claim Google supports those products. What an MCP client needs, per the docs, is:
- A remote HTTP MCP client that can reach your gateway's `/mcp` path.
- Whatever credentials the gateway expects for `tools/list` (if you secured listing) and for each `tools/call` (the same auth the REST operation already required).
If your OpenClaw, Hermes, or similar host can talk to a remote MCP server that way, this is one more server URL in its config. Test with a narrow read tool before you expose write operations. Our posts on local vs remote MCP servers and trust boundaries for self-hosted AI agents cover the same remote-server decision for other stacks.
Where it sits next to other MCP gateways
We have covered three other enterprise MCP surfaces. Nightfall's MCP Gateway is a proxy in front of MCP servers developer tools already use. The AgentCore multi-account hub puts one AWS gateway in front of MCP servers each team runs in its own account. Databricks Genie One MCP is a managed data-answer tool governed through Unity Gateway. Google Cloud API Gateway sits on the REST side: your existing OpenAPI operations become the tools, served from the same gateway that already fronts those APIs.
| Question | Nightfall MCP Gateway | AgentCore multi-account hub | Genie One MCP | Google Cloud API Gateway MCP |
|---|---|---|---|---|
| Who runs the tool? | Your existing MCP servers | Each team, in its own AWS account | Databricks | Your REST backends behind API Gateway |
| Where is the check? | Proxy between developer tools and servers | Cedar policy at the gateway, then each team's server | Unity Catalog grants and Unity Gateway policies | Shared API Gateway auth, quota, and logging on REST and MCP |
| What does the agent get? | Results from allowed MCP tools | Results from typed team MCP tools | Natural-language answers and SQL results | MCP tools mapped from OpenAPI REST operations |
When it is the wrong tool
Skip this Preview when you need MCP resources, prompts, streaming tool results, or OpenAPI 2.0 without a migration. Skip it when the operation returns an empty body such as HTTP 204, or when you need more than 1,000 tools on one config. Skip it when you need a proxy that governs many third-party MCP servers on developer laptops; that is closer to the Nightfall pattern. Skip it when the real need is governed natural-language answers over a data warehouse; that is closer to Genie One. If you need a custom typed MCP with approval gates and idempotency you control end to end, build that server and harden it; see securing a production MCP server.
What to check before you connect an agent
- 1Confirm the API uses OpenAPI 3.0.x or 3.1.x, not 2.0.
- 2Turn on MCP with `x-google-api-management.mcp` and give every exposed operation a backend plus a non-empty description that states when to call it.
- 3Opt out of operations that should stay REST-only with `x-google-mcp-tool: false`.
- 4Secure `tools/list` with JWT or API key via `tools-list.security` before production.
- 5Confirm each `tools/call` path still enforces the REST operation's auth.
- 6Check empty-body and nested-schema limits against the ops you care about.
- 7Keep MCP and model routing out of the same API config.
- 8Point a test client at `/mcp`, send `MCP-Protocol-Version` after initialize, and verify list and call against a low-risk read operation.
- 9Confirm quota and logging treat MCP and REST as one policy path.
- 10Re-read the overview and configure docs before you expose write tools to an agent.
How this fits implementation work
OrchestriAI does not resell or operate Google Cloud API Gateway for clients. MCP development builds narrow typed tools when OpenAPI-to-MCP is the wrong shape or when Preview limits block the use case. AI agent systems decide which agents may call which tools and where a person approves. Systems integration connects the agent host, gateway credentials, and the REST backends already behind the gateway.
Independence and limitations
OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Google, Nightfall, Amazon Web Services, Databricks, OpenClaw, or Nous Research / Hermes. This article summarizes the Google Developers Blog post Turn your REST APIs into MCP tools with Google Cloud API Gateway (September 24, 2026), the MCP overview and configure MCP docs as updated October 9, 2026, and the API Gateway release notes, all checked on October 12, 2026, plus our existing gateway posts. We have not run Google Cloud API Gateway MCP ourselves. Features, auth details, limits, and Preview terms can change, so confirm current Google Cloud documentation before you connect an agent to production APIs. This is not a security certification or a compliance conclusion.
