Google Cloud API Gateway MCP: What to Check Before Exposing REST APIs

Google Cloud's API Gateway can now present existing REST operations as Model Context Protocol (MCP) tools. For a team with APIs already behind the gateway, that removes the need to run a separate MCP server for a first integration. It also makes one configuration choice consequential: which operations become available for an agent to discover and call?

Google announced the capability in Public Preview on September 24, 2026. The gateway reads an OpenAPI 3.x specification, exposes selected operations through an HTTP MCP endpoint and translates tools/call requests into ordinary REST requests. The backend does not need to understand MCP. Google's configuration guide sets out the authentication rules and deployment steps.

Choose which operations agents can use

Enabling x-google-api-management.mcp for a specification exposes every eligible operation by default. An operation needs a configured backend and a description; supported methods include GET, POST, PUT, PATCH and DELETE. You can customize a tool with x-google-mcp-tool or set that extension to false on an operation you want to exclude. Google's configuration guide also notes that adding the object form of the MCP setting to secure tool discovery still enables MCP globally. Review every eligible operation before deployment.

Imagine an order service with getOrderStatus, changeDeliveryAddress and cancelOrder. A support agent may only need the first operation. Exposing all three turns a read-only assistant into a potential writer, even if its prompt says it should only answer questions. Document the exact operations the agent needs, exclude the rest, and test the resulting tools/list response. For a broader discussion of operation names, errors and idempotency, see Bayseian's API design guide for AI agents.

Descriptions also deserve review. The tool name and description help an agent decide when to call an operation. State its purpose and side effects in plain language. A vague description of cancelOrder is especially risky when the underlying REST endpoint changes a real customer record.

Protect discovery separately from calls

The preview treats discovery and invocation differently. tools/list, which reveals tool names and input schemas, is unauthenticated by default. Google recommends protecting it with a JWT security scheme; API keys cannot secure tools/list in this preview. tools/call uses the authentication configured for the underlying REST operation, including its API key or JWT requirements. These are separate checks, so securing the call does not hide the tool catalog. Google's authentication model describes both paths.

For an enterprise rollout, verify both paths with an unauthorized client and an authorized agent. Check whether the catalog exposes internal operation names or parameter shapes, then confirm that a caller without the required operation credential cannot invoke a tool. Existing gateway quotas and logs apply to the translated REST call, according to Google's announcement. Use those records to inspect what the agent attempted; do not treat a successful MCP handshake as proof that the operation is appropriately scoped.

Check the preview limits against the workflow

API Gateway's MCP support is a focused bridge from REST operations to tools. The product overview says MCP resources and prompts, streaming and long-running tool calls are not supported. MCP and model routing cannot be enabled in the same API configuration. Google's announcement adds that operations returning an empty body, such as HTTP 204, are not exposed, and that deeply nested object schemas may not render fully in tools/list. If your workflow depends on one of these behaviors, test a different integration pattern before committing to the gateway path.

The gateway also does not decide whether a business action needs human approval. That remains a design decision in the agent and the underlying service. For a write operation, test what happens when the agent retries after a timeout and whether the backend prevents duplicate effects.

A small acceptance test

Choose one low-risk read operation. Confirm that its description and input schema make sense in tools/list, protect discovery where appropriate, and call it with both valid and invalid credentials. Inspect the gateway log and the returned MCP result. Then try an excluded write operation and verify it is absent from discovery and cannot be invoked through the MCP endpoint. Finally, run the same checks after any OpenAPI change, because adding an eligible operation to a globally enabled specification can expand the agent's tool surface.

For teams planning an agent that connects several business systems, that test is a useful starting point for designing the wider AI system. It keeps the first MCP integration small enough to review while leaving the service's existing access controls in place.