tokenise by Rosvetic

AI for developers, minus the hype

Tools How-to

Google Cloud API Gateway can now serve your REST API as MCP tools

Annotate an OpenAPI spec, redeploy, and agents get tools without a separate MCP server to run.

3 min read

Google Cloud API Gateway can now act as a remote Model Context Protocol server for your existing REST APIs. The feature is in public preview, announced on Google’s developer blog on September 24. You mark up an OpenAPI spec, deploy as usual, and the gateway translates MCP requests into REST calls to your backend.

For teams with a pile of internal APIs and a growing number of agents that want to call them, that skips writing and hosting a bespoke MCP server per service. Authentication, quota and logging policies carry over, since the gateway is still the thing in front of your API.

The setup

You need an OpenAPI 3.0.x or 3.1.x spec. OpenAPI 2.0 isn’t supported, so a gateway still on a 2.0 spec has to migrate first.

Add mcp: true under x-google-api-management, and give each operation a description and a backend. This is Google’s example, an order lookup:

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

x-google-api-management:
  mcp: true                 # expose this spec's operations as MCP tools
  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

Deploy the API config as usual. Per the post, the gateway generates an MCP-aware configuration and serves MCP on the /mcp path, with no extra infrastructure to provision. Point any MCP client at that endpoint with your credentials.

Write the tool description for the model

The x-google-mcp-tool block is where most of the quality comes from. The tool description is what the agent reads when it decides whether to call the tool. Google’s example says what the tool does and when to use it (“Use this when the user asks where an order is…”). Copying your OpenAPI summary there usually isn’t enough, because that text was written for humans browsing docs.

Lock down discovery

Out of the box, tools/list, the method an agent uses to see what tools exist, is unauthenticated. Google says to require JWT authentication for production, and notes that API keys can’t secure this method:

x-google-api-management:
  mcp:
    tools-list:
      security:
        orderServiceJwt: []   # the object form also enables MCP globally

If you leave discovery open, anyone who finds the gateway URL can read a catalog of what your API does.

Limits to know about

  • Operations that return empty bodies (HTTP 204) aren’t exposed
  • A gateway tops out at 1,000 tools
  • You can’t enable MCP and model routing on the same gateway
  • Response streaming and MCP resources and prompts are on the roadmap, not shipped

It’s a preview, so expect changes. If you’re evaluating it, start with one read-only endpoint, since an agent that can only look things up has a much smaller blast radius than one that can issue refunds.