How to Turn REST APIs into MCP Tools with Google Cloud API Gateway

Google Cloud’s official announcement describes API Gateway support for remote MCP servers. An existing OpenAPI 3.0.x or 3.1.x definition can be annotated with Google-specific MCP extensions, then deployed through the normal API Gateway workflow. The gateway accepts MCP JSON-RPC requests, maps tool calls to REST operations, and maps the backend response back into MCP format.

That means a team does not have to rebuild every capability as a separate MCP server before an agent can discover it. The gateway becomes a translation and policy point in front of the API you already operate. It also means the OpenAPI description is no longer only documentation: its names, descriptions, parameters, schemas, and annotations influence what an agent can discover and invoke.

This is complementary to an agent runtime such as the managed harness discussed in our ​Agents API architecture guide. The gateway exposes capabilities; the agent runtime decides when to use them, subject to the permissions your application provides.

Google’s documentation says tools/list is unauthenticated by default in this preview, while tools/call enforces authentication for the underlying REST API. A team can secure tools/list with JWT, but API keys cannot be used to secure that discovery request. This creates a boundary that deserves explicit testing: tool metadata may be visible to a caller even when tool execution is denied.

A tool name and description can leak operational information. For example, a tool called rotate-production-key, even if every call is rejected, tells an attacker that the capability exists. Treat discovery metadata as an information surface. Use neutral descriptions where appropriate, secure discovery when the threat model requires it, and avoid placing tenant data, secrets, internal hostnames, or privileged workflow details in descriptions and schemas.

The backend must still authorize the actual operation for the authenticated principal and tenant. Gateway-level authentication answers who reached the route; it does not automatically answer whether that user may update this invoice, export that dataset, delete this resource, or trigger a production deployment.

The practical workflow starts with an existing OpenAPI definition and adds MCP annotations to the operations you want agents to discover. The exact extension fields and deployment syntax should be checked against Google Cloud’s current preview documentation, but the design principle is stable: make the tool contract small, explicit, and safe to retry.

A read-only operation is a better first candidate than a destructive write. Give it a useful operation name, a bounded parameter schema, a response schema that omits sensitive fields, and backend authorization that is independent of the model’s interpretation.

The announcement lists meaningful preview boundaries. The current path is for REST and OpenAPI 3.x backends. MCP resources and prompts are not available in the same way as tools, streaming support and Model Armor payload inspection are on the roadmap, and empty-body HTTP 204 responses are not exposed as MCP tools. Deeply nested schemas may not render completely in tools/list, and the preview has a 1,000-tool limit.

There is also an architecture constraint: MCP and model routing cannot be enabled in the same API configuration. That matters if a team expects one gateway configuration to serve both model-routing traffic and MCP tools. Separate the concerns deliberately and document the operational ownership of each gateway configuration.

For an agent system that needs richer resources, prompts, streaming, or custom mediation, a dedicated MCP server may still be the better fit. The gateway is most compelling when the main value is safely exposing a curated slice of an existing REST estate without duplicating every backend integration.

Before exposing a tool, inventory its data classification, side effects, identity requirements, quota behavior, failure modes, and rollback path. Then test the complete chain: discovery, authentication, parameter validation, tenant authorization, backend execution, response mapping, logging, retries, and cancellation. An agent can call the same operation repeatedly or with an incomplete understanding of its consequences, so deterministic controls must sit outside the model.

The same principle applies to agent workflows built with Python: keep tool boundaries narrow and test them independently, as described in our production AI agent engineering guide. For security-sensitive agent research, our PageBreak analysis also shows why discovery and verification should be separated from execution authority.

A REST-to-MCP bridge does not prove that an API is safe for autonomous use. It proves that the protocol boundary can be standardized. Reliability, authorization correctness, data minimization, cost control, and human accountability still belong to the system owner.

It also does not mean every REST endpoint should become a tool. An agent-facing contract should be curated for clear intent and bounded consequences. A large legacy API may be technically exposable but operationally confusing, overly permissive, or too easy to misuse.

The durable takeaway is simple: use API Gateway when it reduces integration duplication while preserving your existing controls, but make the MCP surface smaller and safer than the underlying API surface.