AI Engineering

Google API Gateway Turns OpenAPI Into an MCP Boundary

Google Cloud's API Gateway MCP preview lets teams expose selected REST operations as agent tools directly from OpenAPI 3.x, with gateway-level auth and sharp preview limits.

Google Cloud added Model Context Protocol support to API Gateway on September 11, 2026. The feature is in Public Preview, but the architectural signal is already clear: MCP servers are moving from hand-written adapter processes into the same API management layer teams already use for REST traffic.

That is a useful direction. Most companies do not need another bespoke server just to let an agent call GET /orders/{id}. They need a controlled way to publish a narrow tool surface, attach authentication, keep the existing backend unchanged, and make the contract reviewable in code. Google is now offering that path through OpenAPI 3.x extensions on API Gateway.

What Happened

The API Gateway release notes for September 11, 2026 say you can configure API Gateway to act as a remote MCP server. The preview lets you expose existing REST APIs to AI agents as tools without changing the backend service. The enabling mechanism is an OpenAPI 3.x document annotated with Google-specific extensions.

The new documentation describes API Gateway as a proxy between MCP clients and REST backends. An agent sends JSON-RPC messages to the gateway's MCP endpoint, typically POST /mcp or POST /v1/mcp when the API uses a versioned base path. The gateway validates the request, checks authentication, maps the MCP tool call into an HTTP request using the deployed API config, forwards that request to the backend, then converts the backend response back into an MCP JSON-RPC response.

The supported MCP surface is deliberately small. During Public Preview, API Gateway supports initialize, notifications/initialized, tools/list, and tools/call. It does not support MCP resources, prompts, sampling, completion, ping, logging, stdio transport, streaming, or long-running tool calls. OpenAPI 2.0 is also out of scope.

There is one important product boundary: MCP and API Gateway's model routing feature are mutually exclusive in the same API configuration. If x-google-api-management.mcp is enabled, you cannot use x-google-model-router in that config.

Why It Matters

The obvious read is that Google made it easier to publish REST APIs as MCP tools. The more interesting read is that the gateway becomes the governance point for agent integration.

Early MCP deployments often look like local stdio servers: a command starts a process, the agent talks JSON-RPC over stdin and stdout, and the process calls whatever internal APIs it needs. That is useful for developer machines and controlled automation, but it is awkward as an enterprise integration pattern. You now have a new service to deploy, a new auth story, a new observability surface, a new catalog entry, and often a second schema describing the same business API.

Using API Gateway changes the center of gravity. The OpenAPI document already describes paths, methods, parameters, request bodies, response shapes, security schemes, backends, and quota policy. MCP exposure becomes another property of that contract rather than a separate integration project. That matters because tool declarations are not passive documentation. They shape what an agent believes it can do.

In MCP, tools/list gives the client tool names, descriptions, and input schemas. The model then decides when to call a tool based partly on that metadata. A vague tool description is an operational bug. A dangerous operation exposed globally is a security bug. A schema that hides a required business invariant is a reliability bug. Putting those choices in OpenAPI makes them visible to the same review process that should already govern public and internal APIs.

This also helps with incremental adoption. A team can start with a small set of read-only operations, test how agents select and call them, then expose more operations as trust and eval coverage improve. They do not have to build a full MCP adapter service before discovering whether the API surface is safe or useful.

How It Works

At the document level, MCP is configured under x-google-api-management. The extension already owns API management settings such as backends, quotas, and AI model routing configuration. It now accepts an mcp field, either as a boolean or as an object.

The blunt version is:

openapi: 3.0.3
info:
  title: Inventory API
  version: 1.0.0
x-google-api-management:
  mcp: true
  backends:
    inventory-backend:
      address: https://inventory.example.run.app
x-google-backend: inventory-backend

That globally enables MCP for eligible operations. Eligibility is constrained. Only GET, POST, PUT, PATCH, and DELETE operations can be exposed as tools. Each exposed operation needs a backend. Each generated tool needs a unique name matching the documented character and length constraints. Each tool also needs a non-empty description, either from the operation description, the summary, or an override.

Global enablement is convenient, but it is also the dangerous default for real systems. In most APIs, not every operation should be an agent tool. Some endpoints are too broad, too destructive, too administrative, too dependent on hidden context, or too hard to validate through a language model interface.

The better pattern is to expose operations explicitly with x-google-mcp-tool:

paths:
  /v1/incidents/{incidentId}:
    get:
      operationId: getIncident
      summary: Get incident status and current owner.
      x-google-backend: incident-backend
      x-google-mcp-tool:
        name: get_incident_status
        description: "Read current status, severity, owner, and timestamps for one incident."

The object form lets you override the generated name and description. That is not cosmetic. Tool names and descriptions are part of the agent interface. deleteShelf might be acceptable for a client SDK, but an agent-facing description should say whether the operation is permanent, whether it affects child resources, and whether it should be used only after confirmation.

Authentication is split by MCP method. The lifecycle methods initialize and notifications/initialized are unauthenticated. tools/call reuses the security policy of the underlying OpenAPI operation, so an operation protected by API key or JWT remains protected when called through MCP. tools/list is different: by default, discovery is unauthenticated. Google strongly recommends protecting it with tools-list.security, and the preview supports JWT for that method, not API keys.

That creates a practical review checklist. A gateway that exposes sensitive tool names without authenticating tools/list may leak internal capabilities even if tools/call itself is protected. Tool discovery is part of the attack surface because it tells clients what actions exist, what schemas they accept, and sometimes how business workflows are named.

Argument mapping is straightforward. Path and query parameters become top-level properties under MCP arguments. Request bodies are nested under body. Headers can also become top-level properties and are injected as HTTP headers, with restrictions on reserved system headers and x-google- names. Google notes that the backend cannot programmatically distinguish a direct REST request from one transcoded from MCP. That is elegant, but it also means any policy that needs to treat agent-originated calls differently must live at the gateway, client, auth, or application-level identity layer rather than relying on the backend to infer it.

Example

Imagine an internal deployment service with a mature REST API and an OpenAPI 3.x contract. Engineers want coding agents to read deployment status and trigger a rollback during incident response, but only when the caller has the same authorization they would need in the web console.

Do not start by exposing the entire deployment API. Start with a tiny tool surface:

openapi: 3.0.3
info:
  title: Deployment API
  version: 1.0.0

components:
  securitySchemes:
    corpJwt:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-auth:
        issuer: https://identity.example.com
        jwksUri: https://identity.example.com/.well-known/jwks.json
        audiences:
          - deployment-api

x-google-api-management:
  mcp:
    tools-list:
      security:
        corpJwt: []
  backends:
    deploy-backend:
      address: https://deployments.example.run.app

paths:
  /v1/services/{service}/deployments/latest:
    get:
      operationId: getLatestDeployment
      summary: Read latest deployment state for a service.
      security:
        - corpJwt: []
      x-google-backend: deploy-backend
      x-google-mcp-tool:
        name: get_latest_deployment
        description: "Read the latest deployment version, status, actor, and timestamps for one service."

  /v1/services/{service}/rollback:
    post:
      operationId: rollbackService
      summary: Roll back a service to the previous stable deployment.
      security:
        - corpJwt: []
      x-google-backend: deploy-backend
      x-google-mcp-tool:
        name: rollback_service
        description: "Request rollback of one service to the previous stable deployment after operator approval."

With that config deployed, an MCP client can discover tools through tools/list and invoke them through tools/call. For the rollback operation, a call would pass the path parameter at the top level and the body, if needed, under body:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "rollback_service",
    "arguments": {
      "service": "checkout-api",
      "body": {
        "reason": "Rollback requested during incident INC-1427"
      }
    }
  }
}

The model should not be the only protection around that operation. The MCP specification says applications should provide clear UI around exposed tools and keep a human able to deny invocations. The API should still validate authorization, service names, rollout state, idempotency, and incident linkage. The gateway mapping makes the operation reachable by agents; it does not make the operation safe by itself.

My Take

This preview is the shape I want cloud providers to pursue for agent integration: declarative, boring, and close to existing infrastructure.

The worst version of MCP adoption is a pile of thin servers that re-describe mature APIs in a second format, each with slightly different authentication, logging, deployment, and error semantics. That path makes demos fast and operations weird. It also tempts teams to hide too much policy in prompt text because the integration layer has no real governance surface.

Google's API Gateway approach is more honest. It says the tool boundary is an API boundary. That means the work is mostly API design: pick operations carefully, write agent-useful descriptions, bind schemas precisely, keep discovery authenticated, preserve existing operation-level auth, and treat write tools as privileged interfaces.

The preview limits are not footnotes. No resources or prompts means this is not a full MCP application platform. No streaming or long-running calls means it is a poor fit for jobs that need progress updates, resumability, or deferred retrieval. Statelessness means you should not expect gateway-maintained MCP sessions. No tool annotations means clients will not receive hints like readOnlyHint or destructiveHint from these generated declarations. The 1,000-tool gateway limit is generous for curated APIs and terrifying if you accidentally expose a sprawling internal surface.

That last point is worth dwelling on. The operational mistake will be enabling mcp: true globally on a large OpenAPI spec and calling it done. Agents do not need your entire API. They need a small number of stable, well-described capabilities with schemas that leave little room for improvisation. The right default is explicit opt-in, especially for mutation endpoints.

I also like the mutual exclusion with model routing, even though some teams will find it annoying. Routing model traffic and exposing business operations as MCP tools are different gateway roles. Combining both in one config would make the edge harder to reason about. Separate gateways force a cleaner mental model: one surface routes inference requests, another surface exposes operational tools.

For teams already on Google Cloud, this is worth testing now, but not because Public Preview is a promise of production stability. Test it to learn which REST operations make good tools, which descriptions cause bad tool selection, how your auth model behaves when tool discovery is involved, and what observability you need around agent-originated calls. Those lessons will survive even if the preview changes.

Conclusion

Google Cloud's September 11 API Gateway MCP preview is a meaningful step toward production-grade agent plumbing. It lets teams turn selected OpenAPI 3.x REST operations into MCP tools without rewriting backend services, while keeping the gateway in charge of mapping, authentication, and deployment.

The feature is intentionally constrained: tools/list and tools/call, HTTP POST, OpenAPI 3.x, no resources, no prompts, no stdio, no streaming, no long-running calls, and no coexistence with model routing in the same API config. Those constraints make it less glamorous than a custom MCP server, but also easier to understand.

The engineering move is simple: treat MCP exposure as part of API design. Review every tool name. Review every description. Authenticate discovery. Prefer explicit per-operation opt-in. Keep write operations narrow. Validate everything again in the backend. If you do that, API Gateway can become a clean bridge between existing REST systems and the agent clients now showing up at the edge of engineering workflows.