Google Cloud API Gateway turns REST specs into MCP tools

Every team that has tried to plug an agent into an internal API knows the problem: the routing, authentication, and quota logic already lives in the gateway, but for the agent to see that as an MCP tool, someone has to reimplement all of it from scratch in a dedicated MCP server. That duplicated work is what Google Cloud tackled in its September 24, 2026 announcement: API Gateway now works as a remote MCP server, in Public Preview, transcoding tools/call calls into ordinary REST requests against the OpenAPI spec you already publish.

It's worth separating this from the rest of Google's gateway portfolio, because picking the wrong one gets expensive later. API Gateway is the lightweight entry point: if you have a service on Cloud Run and want to expose it securely in minutes, this is the fast path. For full lifecycle management, advanced traffic policies, and monetization, the product is Apigee. For controlling what your own agents call out to (including other MCP servers like this one), that's Agent Gateway. And if what you need is a stable endpoint for outbound LLM calls, that's Model Routing, which in fact cannot be enabled in the same API config as MCP.

How the transcoding works under the hood

The gateway accepts standard MCP JSON-RPC requests on a single endpoint, turns each tools/call into the corresponding REST request, applies the policies you had already configured for that operation, and translates the response back into MCP format. Because the transcoded request is indistinguishable from a normal REST call, the JWT or API key, the quota, and the logging you already had for that operation keep working unchanged. MCP and REST share exactly the same policy path, and an operation consumes the same quota allocation no matter which route it was called through.

Annotating your OpenAPI spec: the first real step

The entry requirement is that the spec be in OpenAPI 3.0.x or 3.1.x (2.0 is not supported), so if your gateway still runs an old spec, migration comes before anything else. You opt into MCP at the document level with x-google-api-management.mcp: true and customize (or skip) specific operations with x-google-mcp-tool. Every exposed operation needs a backend and a non-empty description:

openapi: 3.0.4
info:
  title: Order Service
  version: 1.0.0

x-google-api-management:
  mcp: true

backends:
  orders-backend:
    address: https://orders-a1b2c3-uc.a.run.app

paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: Returns the current status, carrier, and ETA for an order.
      x-google-backend: orders-backend
      x-google-mcp-tool:
        name: get_order_status
        description: "Look up the delivery status and ETA of a customer order. Use this when the user asks where an order is or when it will arrive."
      parameters:
        - name: orderId
          in: path
          required: true
          schema:
            type: string

The detail that makes a practical difference: the x-google-mcp-tool description is the main signal the LLM uses to decide when to call the tool. Writing "returns the order status" is much weaker than explaining when and why to use it, as in the example above. This is prompt engineering disguised as API documentation, and it's worth the extra review time.

Deployment, discovery security, and the most common stumbling block

Deployment is the same as always: you push your API config as usual, and the gateway already generates the MCP-aware configuration, serving on the base path /mcp, with no extra infrastructure to provision. The point I'd flag as the most likely stumbling block for anyone adopting this is tools/list security: by default, listing available tools is an unauthenticated call, which is convenient in development but publishes tool names and input schemas to anyone who asks. In production this needs JWT (API keys don't work to protect this specific method):

mcp:
  tools-list:
    security:
      orderServiceJwt: []

tools/call, on the other hand, always applies whatever authentication the underlying REST operation requires, regardless of whether you secure discovery or not. In other words: forgetting to lock down tools-list doesn't expose you to unauthorized calls, but it does expose your tool catalog to any curious eye, which is already too much information in many corporate contexts.

Connecting an agent and inspecting the traffic

For those using the Agent Development Kit, the fit is direct: an McpToolset pointing to the gateway's /mcp endpoint, with the credential header the gateway already expects.

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams

order_tools = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp",
        headers={"x-api-key": API_KEY},
    )
)

agent = Agent(
    model="gemini-2.5-flash",
    name="order_support_agent",
    instruction="Help the user check on their orders.",
    tools=[order_tools],
)

If I were validating this integration before trusting it, the first test would be hitting the endpoint directly with curl, bypassing the agent, just to confirm the transcoding is coming out as expected:

curl -X POST "https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp" \
  -H "content-type: application/json" \
  -H "MCP-Protocol-Version: 2025-11-25" \
  -H "x-api-key: $API_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_order_status","arguments":{"orderId":"A-1042"}}}'

The response documented by Google shows the expected return format, with the original API body embedded as text inside the MCP envelope:

{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"{\"orderId\":\"A-1042\",\"status\":\"IN_TRANSIT\",\"eta\":\"2026-09-24\"}"}],"isError":false}}

If the response comes back empty or with a schema error, the obvious debugging path is to check whether the operation has a non-empty description and a declared backend, the two requirements Google lists as mandatory for an operation to become an MCP tool.

What doesn't work yet, and what changes for those already using Apigee

The Public Preview covers REST backends and OpenAPI 3.x with the authentication you already have configured. MCP resources and prompts, response streaming, and payload inspection via Model Armor are on the roadmap, not available yet. There are limits worth noting before you architect on top of this: operations that return an empty body, like HTTP 204, simply aren't exposed as a tool; heavily nested object schemas may not render correctly in tools/list; a single gateway serves at most 1,000 tools; and MCP and Model Routing cannot coexist in the same API config.

For those already running Apigee, the natural question is whether this replaces the platform. It doesn't: Google's own announcement explicitly positions API Gateway as the lightweight "on-ramp" and leaves full API lifecycle management to Apigee. The real gain here is for anyone with a simple API running on Cloud Run or GKE who wants to make it discoverable to a Gemini Enterprise agent or any MCP client compatible with Streamable HTTP, without standing up a new piece of infrastructure. If your API already lives inside Apigee, the path to agent integration runs through a different product in the same family, not this one.