---
title: "Google Cloud API Gateway exposes REST endpoints as MCP tools without custom middleware"
canonical: https://www.aa-labs.co/blog/google-cloud-api-gateway-exposes-rest-endpoints-as-mcp-tools-without-custom-middleware
author: A & A Labs
published: 2026-10-12
updated: 2026-10-12
category: Engineering
publisher: A & A Labs (Private) Limited
reading_minutes: 5
---

# Google Cloud API Gateway exposes REST endpoints as MCP tools without custom middleware

> Google Cloud API Gateway in Public Preview acts as a remote MCP server, converting REST operations into agent-ready tools by annotating an OpenAPI 3.x spec. Authentication, quota and logging stay unchanged because MCP calls are transcoded into standard REST requests.

## Key takeaways

- API Gateway transcodes MCP JSON-RPC to REST, reusing existing auth, quota, and logging policies
- Enable MCP with x-google-api-management.mcp: true in OpenAPI 3.x spec; customise tools via x-google-mcp-tool
- tools/list is unauthenticated by default; secure it with JWT for production (API keys not supported)
- Quota is shared between MCP and REST calls — monitor combined usage for high-volume endpoints
- Public Preview limits: no OpenAPI 2.0, no streaming, no Model Armor, 1,000 tools max per gateway

Google Cloud API Gateway now acts as a remote Model Context Protocol (MCP) server in Public Preview, turning existing REST operations into agent-ready tools by annotating an OpenAPI 3.x spec. Platform teams can skip building and operating a separate MCP bridge — authentication, quota, and logging stay exactly as configured for REST traffic.

## How the gateway becomes an MCP server

API Gateway accepts MCP JSON-RPC requests on a single `/mcp` base path, transcodes each `tools/call` into the corresponding REST request, applies existing policies, and translates the response back. Because the transcoded request is indistinguishable from a normal REST call, the JWT or API-key authentication, quota, and logging already configured for that operation keep working unchanged — MCP and REST traffic share exactly one policy path, and a given operation draws on one quota allocation however it is invoked [^1].

The feature sits at the lightweight end of Google's gateway lineup. For a full enterprise API and MCP platform with lifecycle management, advanced traffic policies, and monetisation, Google directs teams to Apigee. To govern what agents call on the way out — including MCP servers like this one — use Agent Gateway. Model routing, which provides one stable endpoint for outbound LLM calls, is the companion capability for the other direction of AI traffic [^1].

In practice, the biggest advantage of exposing existing REST APIs as MCP tools is not simply making them accessible to AI agents, it is avoiding another layer of middleware that needs to be maintained, secured, and monitored. For teams integrating CRMs, ERPs, messaging platforms, and payment systems, keeping tool calls behind an established API gateway can simplify operations considerably. However, shared quota deserves particular attention: an agent making repeated tool calls can consume the same capacity used by existing applications. Before exposing production endpoints, review tool descriptions, secure tool discovery, set appropriate quotas, and monitor agent-driven traffic alongside traditional API usage.

## Annotation requirements

MCP requires OpenAPI 3.0.x or 3.1.x; OpenAPI 2.0 is not supported, so specs still on 2.0 must be migrated first. Opt in at the document level with `x-google-api-management.mcp: true`, and customise or skip individual operations with `x-google-mcp-tool`. Each exposed operation needs a backend and a non-empty description [^1].

```yaml
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 tool description is the primary signal an LLM uses to decide when to call it, so write when and why to use the tool, not just what it returns [^1].

## Authentication flow

By default `tools/list` is unauthenticated, which is convenient for development but publishes tool names and input schemas to anyone who asks. For production, require a JWT — note that API keys cannot secure this method:

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

`tools/call` always enforces whatever authentication the underlying REST operation requires, whether or not discovery is secured [^1].

## Rate-limit behaviour

Quota is shared between MCP and REST invocations of the same operation. A call made through the MCP endpoint consumes the same quota allocation as a direct REST call, so existing rate limits and budgets apply without adjustment. This also means a spike in agent traffic can exhaust quota intended for human-driven integrations, so monitor combined usage if agents will call high-volume endpoints [^1].

## Connecting an agent

Point any MCP client at the gateway's `/mcp` endpoint. In the Agent Development Kit (ADK), that is the toolset plus the credential the gateway already expects:

```python
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],
)
```

On the wire, a `tools/call` request maps the tool's arguments back onto the REST path, query, body, and headers of the operation, runs the request through existing policies, and returns the backend's response as an MCP result [^1].

## Current limits worth knowing

The Public Preview covers REST and OpenAPI 3.x backends with current authentication. MCP resources and prompts, response streaming, and Model Armor payload inspection are on the roadmap. A few limits are worth knowing up front:

- Operations returning empty bodies such as HTTP 204 are not exposed.
- Deeply nested object schemas may not render fully in `tools/list`.
- A gateway serves up to 1,000 tools.
- MCP and model routing cannot be enabled in the same API config [^1].

## What to do next

If your team runs REST services on Cloud Run or Cloud Functions behind API Gateway, annotate one OpenAPI 3.x spec and deploy it to the preview — the operational cost is near zero and the rollback is a single config change. For workloads that need enterprise lifecycle management, advanced traffic policies, or monetisation, plan the move to Apigee's MCP support when it lands. Teams we work with on systems integration — connecting CRMs, ERPs, messaging channels and payment providers — often find the managed gateway reduces the bespoke middleware that otherwise accumulates around agent-tool wiring. See [our systems integration work](https://aa-labs.co/capabilities), and our earlier piece on [Cloudflare AI Gateway's managed web search](https://aa-labs.co/blog/cloudflare-ai-gateway-adds-managed-web-search-for-retrieval-augmented-applications) for related patterns.

[^1]: https://developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/
[^2]: https://aa-labs.co/capabilities
[^3]: https://aa-labs.co/blog/cloudflare-ai-gateway-adds-managed-web-search-for-retrieval-augmented-applications

## Frequently asked questions

### How does Google Cloud API Gateway expose REST endpoints as MCP tools?

API Gateway accepts MCP JSON-RPC requests on a /mcp base path, transcodes each tools/call into the corresponding REST request, applies existing policies, and translates the response back. The transcoded request is indistinguishable from a normal REST call, so JWT or API-key authentication, quota, and logging already configured for that operation keep working unchanged.

### What OpenAPI version is required for MCP support in API Gateway?

MCP requires OpenAPI 3.0.x or 3.1.x. OpenAPI 2.0 is not supported, so specs still on 2.0 must be migrated first.

### How do you enable MCP for an API Gateway configuration?

Add x-google-api-management.mcp: true at the document level in your OpenAPI 3.x spec. Customise or skip individual operations with x-google-mcp-tool. Each exposed operation needs a backend and a non-empty description.

### Can API keys secure the tools/list endpoint in API Gateway MCP?

No. By default tools/list is unauthenticated. For production, require a JWT — API keys cannot secure this method. tools/call always enforces whatever authentication the underlying REST operation requires.

### Is quota shared between MCP and REST invocations?

Yes. Quota is shared between MCP and REST invocations of the same operation. A call made through the MCP endpoint consumes the same quota allocation as a direct REST call, so existing rate limits and budgets apply without adjustment.

## Sources

- Turn your REST APIs into MCP tools with Google Cloud API Gateway — https://developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/

---

Published by A & A Labs (Private) Limited · https://www.aa-labs.co/blog/google-cloud-api-gateway-exposes-rest-endpoints-as-mcp-tools-without-custom-middleware