Four days. That’s how long one of my engineers spent last quarter building a Python service whose entire job was translating REST calls into MCP tool calls, so our support-ticket agent could check order status. Four days of work, plus a new service on the on-call rotation, plus a second copy of the auth logic to keep in sync with the real API. Google just made that service unnecessary, if you happen to run API Gateway.

On September 24, Google Cloud shipped MCP support for API Gateway in Public Preview. The pitch: annotate the OpenAPI spec you already have, redeploy, and the gateway starts speaking MCP JSON-RPC on a single /mcp endpoint — transcoding each tools/call into the REST request behind it, then translating the response back. No separate server. No second auth implementation to drift out of sync with the first.

What the annotation actually looks like

Two levels of opt-in. Document-level, to turn MCP on for the whole spec:

x-google-api-management:
  mcp: true
  backends:
    orders-backend:
      address: https://orders-a1b2c3-uc.a.run.app

And per-operation, to describe the tool an agent will see:

paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      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."

That’s it. No new deployment target, no new base image, no new secret to rotate. The spec has to be OpenAPI 3.0.x or 3.1.x — if you’re still on 2.0 anywhere, that migration is now a prerequisite for agent access, not just a nice-to-have.

The part worth taking seriously: auth doesn’t change

The JWT or API-key check, the quota bucket, and the logging you already configured for that REST operation apply unchanged to the MCP call. One operation, one quota allocation, regardless of which protocol asked for it. That’s the actual win here — not “agents can call your API,” which any hand-rolled wrapper already gave you, but “agents inherit the exact same guardrails your REST clients live under, with zero duplicated policy.”

There’s one sharp edge in that story, though: tools/list — the discovery call an agent uses to see what’s available — is unauthenticated by default. API keys can’t lock it down; you need JWT, applied explicitly:

x-google-api-management:
  mcp:
    tools-list:
      security:
        orderServiceJwt: []

If you skip that, any agent that finds your /mcp endpoint can enumerate every operation you’ve annotated before it ever needs a credential. tools/call still enforces whatever the underlying REST operation requires — so nothing gets executed without auth — but the surface area of your API is visible to anyone who asks. Treat this the way you’d treat an unauthenticated /api/docs route: fine in some contexts, a real finding in others.

Where it stops being convenient

This is Public Preview, and the limits are specific enough that they’ll bite someone within a month of launch. A gateway caps out at 1,000 tools. Operations that return an empty body — your standard 204 No Content — don’t get exposed at all, which means any REST API built around “success means empty body” needs a rethink before it can hand that operation to an agent. Response streaming isn’t supported. MCP resources and prompts, the parts of the spec beyond tool-calling, aren’t either. And you can’t turn on MCP and model routing in the same API config, so if you were hoping to combine this with Gemini-based request routing in one gateway, you’re picking one.

The one line that now matters more than your docs

Here’s the actual behavior change for API teams: the description field on x-google-mcp-tool is no longer documentation. It’s the only signal an LLM has to decide whether your tool is the right one to call for a given user request. Google’s own guidance says it plainly — write when and why to use the tool, not just what it returns.

Most REST descriptions I’ve reviewed over fifteen years read like “Returns order status by ID.” That’s a fine sentence for a human skimming a docs page who already knows they want order status. It’s a bad sentence for an LLM deciding, among forty tools, whether this is the one that answers “where’s my package.” Rewriting descriptions as intent statements — “use this when the user asks where an order is or when it will arrive” — is a five-minute edit per endpoint, and it’s the actual work this feature creates for you. Budget for it; it won’t show up on anyone’s sprint plan otherwise.

Where this fits

If you’re already running Apigee for full API lifecycle management, or Kong, or your own hand-rolled gateway, this doesn’t change anything for you yet — API Gateway is the lightweight tier, and MCP-as-a-platform-feature will presumably show up further up Google’s product line eventually. But if you’re sitting on a REST estate behind plain API Gateway and you’ve been asked to “make this agent-callable” this quarter, skip the wrapper service. Annotate the spec, lock down tools/list, rewrite your descriptions like you mean them, and spend the four days you saved reviewing what an agent should actually be allowed to do with a POST once it can reach one.

Export for reading

Comments