API Gateway MCP Server
GoogleOfficialPublished by Google
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill enables the transformation of REST APIs hosted on Google Cloud API Gateway into remote Model Context Protocol (MCP) servers. By annotating OpenAPI 3.x specifications with specific extensions, the gateway can translate MCP JSON-RPC 2.0 requests into standard HTTP REST calls. The skill provides a structured workflow for migrating OpenAPI 2.0 specs to 3.x, validating configurations, securing the MCP endpoint, and integrating with tools like the Google Agent Development Kit (ADK).
What it does
- Converts REST APIs into MCP-compatible tools via OpenAPI 3.x annotations.
- Validates OpenAPI specifications for MCP compatibility using a provided Python script.
- Configures security for the MCP tools/list endpoint using JWTs or API keys.
- Facilitates integration with Google ADK McpToolset and API hub discovery.
- Provides guidance on troubleshooting common MCP JSON-RPC error codes.
- Manages the lifecycle of API Gateway resources including creation, updates, and deletion.
When to use it
- When you need to expose existing REST APIs as tools for AI agents using the Model Context Protocol.
- When migrating legacy OpenAPI 2.0 specifications to OpenAPI 3.x for MCP support.
- When you need to secure MCP tool discovery with specific authentication schemes.
- When integrating Google Cloud-hosted APIs with agent frameworks like the Google ADK.
Advantages
- Enables standard MCP communication over HTTP for Google Cloud-hosted services.
- Leverages existing API Gateway authentication and quota management policies.
- Supports automated discovery in API hub and Agent Registry.
- Provides a deterministic validation loop to catch configuration errors before deployment.
Usage examples
- “How do I annotate my OpenAPI 3.0 spec to expose a REST endpoint as an MCP tool?”
- The skill provides the necessary x-google-mcp-tool annotations and explains how to define the tool name, description, and request body properties for LLM tool selection.
- “Validate my OpenAPI spec for MCP deployment.”
- The skill guides you to run the provided scripts/validate_mcp_openapi.py script to ensure your specification meets all requirements before attempting to create an API config.
- “How can I connect my agent to the API Gateway MCP server?”
- The skill provides a Python code sample using McpToolset and StreamableHTTPConnectionParams to connect to the gateway's /mcp endpoint.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/google/api-gateway-mcp-server/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip api-gateway-mcp-server.zip -d .agents/skills
Documentation by Google
API Gateway Remote MCP Server (Public Preview)
This skill converts new or existing REST APIs on Google Cloud API Gateway into remote Model Context Protocol (MCP) servers (POST https://{default_hostname}/mcp, Public Preview). By annotating an OpenAPI 3.x (3.0.x or 3.1.x) specification with x-google-api-management.mcp and x-google-mcp-tool, API Gateway translates MCP JSON-RPC 2.0 requests (initialize, notifications/initialized, tools/list, tools/call) into standard HTTP REST requests to your backend while enforcing existing authentication and quota policies.
Attribution
MUST READ: Before executing any gcloud, REST API, or MCP command, you
MUST read Usage Attribution. For commands executed
directly in the terminal (never in generated scripts, Terraform, or user code),
prefix gcloud with
CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:api-gateway-mcp-server)"
and append agent-skills/1.0 (skill:api-gateway-mcp-server) to User-Agent headers.
Prerequisites
Install the Google Cloud CLI and the validator dependency:
Install the Google Cloud CLI. Then update it to the latest version with
gcloud components update. An old CLI can fail when it uploads an OpenAPI 3.x API config.Install Python 3.10 or later and
PyYAMLfor the local OpenAPI MCP validator script:pip install "PyYAML>=6.0,<7.0"
Authenticate your environment:
Local CLI session:
gcloud auth loginApplication Default Credentials (SDKs / ADK):
gcloud auth application-default login
Select or create a project, confirm billing, and pick a supported gateway location:
Select an existing project (
gcloud config set project {project_id}) or create one (gcloud projects create {project_id}).Confirm that an active billing account is linked to
{project_id}. API Gateway has a free monthly allowance of API calls for each billing account, but you still need an active billing account to deploy. Calls above the allowance and network data transfer out are charged. For current prices, see API Gateway pricing.Use
us-central1as the default--locationfor gateway commands. For the other supported regions, see API Gateway deployment model.
Enable the required Google Cloud APIs:
gcloud services enable \ apigateway.googleapis.com \ servicemanagement.googleapis.com \ servicecontrol.googleapis.com \ --project={project_id}For API hub discovery (optional), enable the API hub API in the API hub host project:
gcloud services enable apihub.googleapis.com --project={hub_project_id}. To query Agent Registry (optional), also rungcloud services enable agentregistry.googleapis.com --project={project_id}.Verify the IAM roles (use the most restrictive role for each step):
To create and update the API, API configs, and gateways: API Gateway Admin (
roles/apigateway.admin) on{project_id}. To run thegcloud services enablecommands: Service Usage Admin (roles/serviceusage.serviceUsageAdmin) on that project.To reference the gateway service account in an API config: Service Account User (
roles/iam.serviceAccountUser) on{gateway_sa_name}@{project_id}.iam.gserviceaccount.com.For a Cloud Run backend: grant the gateway service account the Cloud Run Invoker role (
roles/run.invoker) on the service.To mint test ID tokens as a caller service account: Service Account Token Creator (
roles/iam.serviceAccountTokenCreator) on{caller_sa_email}.Reference: Configure the development environment.
Decision Matrix: MCP Server Configuration and Client Integration
| Task | Required Mechanism | Critical Guardrail | Detailed Reference |
|---|---|---|---|
Migrate OpenAPI 2.0 (swagger: "2.0") or author OpenAPI 3.x for MCP | Root x-google-api-management.mcp + named backends + operation-level x-google-mcp-tool | NEVER add MCP extensions to an OpenAPI 2.0 spec. Rationale: MCP is not supported for OpenAPI 2.0. Use OpenAPI 3.0.x or 3.1.x, and deploy the spec with gcloud api-gateway api-configs create. Keep all MCP operations in one OpenAPI document: if an API config has several documents, API Gateway serves the MCP tools of only one of them. | OpenAPI 2.0 to 3.x Migration |
| Optimize tool names, descriptions, and schemas for LLM tool selection | x-google-mcp-tool (name, description, false) + described requestBody properties | Every operation MUST have an operationId, with or without MCP. Every exposed tool MUST resolve to a unique name that matches [A-Za-z0-9_.-]{1,128} (x-google-mcp-tool.name, or else the operationId), a non-empty description, and a non-empty response body (HTTP 204 is unsupported). Only GET, POST, PUT, PATCH, and DELETE operations can be tools, and a gateway serves at most 1,000 tools. API Gateway rejects complex nested schemas when you create the API config, but a simple nested object body works. In OpenAPI 3.1, give each schema one type, because API Gateway also rejects a type list such as type: ["string", "null"]. Describe each property, and check each tool's inputSchema in tools/list after you deploy. | OpenAPI Agent Tool Optimizer |
Secure tools/list and hide internal/admin routes | x-google-api-management.mcp.tools-list.security (exactly one JWT or API key scheme; a JWT scheme is also listed in root security) + x-google-mcp-tool: false | tools/list is unauthenticated by default. It accepts one JWT scheme, or one API key scheme sent in the x-api-key header. API Gateway rejects a config whose JWT tools-list.security scheme is missing from the root security list, and that root entry also requires the JWT on every REST operation without its own security. If the root list already has an API key scheme, add the JWT to the same requirement object (AND): API Gateway does not support alternative (OR) requirements with an API key. An mcp object (for tools-list) also enables MCP for every eligible operation, so opt out each operation that agents must not use. x-google-mcp-tool: false hides a route from MCP only; keep REST security on admin routes. | OpenAPI 2.0 to 3.x Migration |
Connect Google ADK (McpToolset) and discover in API hub / Agent Registry | McpToolset (StreamableHTTPConnectionParams) + API hub project attachment | No separate registration step is needed. After you attach the API Gateway project to API hub, the MCP server appears in API hub as {your_api} (MCP) and in Agent Registry automatically. | ADK and API Hub Discovery |
Verify /mcp JSON-RPC lifecycle and troubleshoot -32601 / -32602 / -32000 errors | POST https://{default_hostname}/mcp with MCP-Protocol-Version: 2025-11-25 | Keep /mcp at the host root: a servers base path (such as /v2) applies to REST paths only, and {basepath}/mcp returns HTTP 404. Nest JSON request bodies under params.arguments.body ({"body": {...}}). NEVER combine x-google-api-management.mcp with x-google-model-router in one config. Rationale: API Gateway does not allow MCP and model routing in the same API config. | MCP Verification and Troubleshooting |
Execution Workflow and Validation Loop
Upgrade and annotate the OpenAPI 3.x specification:
The references in this skill contain the conversion rules: the Swagger 2.0 Construct Conversion Map covers each Swagger 2.0 construct, and the Complete Converted Example shows a finished spec with a Google ID token scheme. Use them before you search other sources.
Follow OpenAPI 2.0 to 3.x Migration and OpenAPI Agent Tool Optimizer to set
openapito a 3.0.x or 3.1.x version (the examples use3.0.4), remove unsupported OpenAPI 2.0 fields (x-google-allow), definex-google-api-management.backends(withjwtAudienceordisableAuth), configurex-google-api-management.mcp.tools-list.securitywith exactly one JWT or API key scheme (add a JWT scheme to the rootsecuritylist too, in the same requirement object as any API key scheme), authorx-google-mcp-tooldescriptions stating when and why to invoke each tool, and opt out administrative routes (x-google-mcp-tool: false).Before you deploy, give the user a short summary that states each of these points, and get approval:
MCP is not supported for OpenAPI 2.0, so you converted the spec to OpenAPI 3.x.
Which operations you exposed as tools, and which you opted out with
x-google-mcp-tool: false. Opted-out operations stay on REST.If
tools/listuses a JWT scheme, the rootsecurityentry makes every REST operation without its ownsecurityrequire the JWT. The gateway rejects REST callers without it.The MCP endpoint is
https://{default_hostname}/mcp, at the host root even when the spec sets aserversbase path.The limits that apply: only
GET,POST,PUT,PATCH, andDELETEoperations can be tools, a gateway serves at most 1,000 tools, request parameters must be primitive types, API Gateway rejects complex nested schemas and OpenAPI 3.1 type lists (such astype: ["string", "null"]) when you create the API config, tools cannot returnHTTP 204, and MCP is stateless with UTF-8 text responses only.
Give the same points when the user only asks for the converted spec or for advice, without a deploy.
Preserve exact quota metric names in
x-google-api-management.metricsacross API configs so existing gateways do not fail with HTTP 500Failed to call Service Control Quota.
Run the deterministic MCP OpenAPI validation loop before creating the API config:
Execute
scripts/validate_mcp_openapi.pyon{candidate_openapi_spec}:python3 scripts/validate_mcp_openapi.py --spec={candidate_openapi_spec}If
scripts/validate_mcp_openapi.pyexits with code1(status: "FAIL"), fix every reported error in{candidate_openapi_spec}(such as OpenAPI 2.0 syntax,x-google-allow, path-levelx-google-mcp-tool, undefined backend names, an operation without anoperationId, missing descriptions, invalid or duplicate tool names, a header parameter with the reservedx-google-prefix, atools-list.securityscheme that is neither anoauth2JWT nor anapiKeyscheme, a JWTtools-list.securityscheme missing from the rootsecuritylist, alternative (OR) security requirements with an API key, or anx-google-model-routeroperation in an MCP spec) and re-run the script until it exits with code0(status: "PASS"). If it exits with code2, fix the file path or YAML syntax error printed to stderr.Read every warning (such as an
HTTP 204response, a request parameter that is not a primitive type, or operations that anmcpobject exposes by default). Fix it, or tell the user why you keep it.
Create the API (if new), create the API config, deploy the gateway, and enable the managed service (request human approval before updating a production gateway):
gcloud api-gateway apis create {api_id} --project={project_id} gcloud api-gateway api-configs create {config_id} \ --api={api_id} \ --openapi-spec={candidate_openapi_spec} \ --backend-auth-service-account={gateway_sa_name}@{project_id}.iam.gserviceaccount.com \ --project={project_id} gcloud api-gateway gateways update {gateway_id} \ --api={api_id} \ --api-config={config_id} \ --location={region} \ --project={project_id} gcloud services enable $(gcloud api-gateway apis describe {api_id} --project={project_id} --format="value(managedService)") --project={project_id}(For a brand-new gateway, run
gcloud api-gateway gateways create {gateway_id} ...instead ofgateways update).Run one
api-configs createat a time per API. Wait for it to finish before you start the next one, because API Gateway creates only one config for an API at a time. A complex API config can take up to ten minutes to create.If clients use API keys from other projects, enable the managed service in each of those projects too. API Gateway rejects an API key unless the API is enabled in the project that created the key.
Verify the JSON-RPC 2.0 lifecycle and connect ADK / API hub:
Send every probe to
https://{default_hostname}/mcp, even when the spec sets aserversbase path.An HTML
404 Page not foundmeans that the gateway may not be deployed correctly. Check that the gateway state isACTIVEand that the last create or update finished, and retry before you change the config. During a gateway update, some requests can still reach the previous API config. A JSON 404 (The current request is not defined by this API.) means that the active config does not define the path.If
tools/listrequires a JWT, mint a Google ID token whose audience is inx-google-auth.audiences:gcloud auth print-identity-token --impersonate-service-account={caller_sa_email} --audiences={jwt_audience}. Iftools/listrequires an API key, send it in thex-api-keyheader.Run the
initialize,notifications/initialized,tools/list, andtools/callverification probes in MCP Verification and Troubleshooting.Connect Google ADK (
McpToolset) and verify automatic catalog discovery in Apigee API hub ({your_api} (MCP)) and Agent Registry using ADK and API Hub Discovery.
Pre-Deployment Checklist
[ ] Specification version is
openapi: 3.0.xor3.1.x(notswagger: "2.0"), omitsx-google-allow, and does not containx-google-model-router.[ ]
python3 scripts/validate_mcp_openapi.py --spec={candidate_openapi_spec}returnsstatus: "PASS"(exit code0).[ ] Every operation has an
operationId, and all MCP operations are in one OpenAPI document.[ ]
x-google-api-management.mcp.tools-list.securitynames exactly one scheme: anoauth2JWT scheme withx-google-auththat the rootsecuritylist also references, or anapiKeyscheme within: headerandname: x-api-key.[ ] If
tools/listuses a JWT scheme, the user knows that REST operations without their ownsecuritynow require that JWT.[ ] Administrative, health-check, and
HTTP 204endpoints are opted out withx-google-mcp-tool: false, and opted-out admin paths remain protected on REST.[ ] MCP clients call
https://{default_hostname}/mcp(not{basepath}/mcp), nesttools/callJSON request bodies insideparams.arguments.body, and sendMCP-Protocol-Version: 2025-11-25.
Resource Cleanup
To avoid ongoing charges when tearing down a test or staging environment, request human approval and delete the gateway, API config, API, and service account in dependency order:
gcloud api-gateway gateways delete {gateway_id} --location={region} --project={project_id}
gcloud api-gateway api-configs delete {config_id} --api={api_id} --project={project_id}
gcloud api-gateway apis delete {api_id} --project={project_id}
gcloud iam service-accounts delete {gateway_sa_name}@{project_id}.iam.gserviceaccount.com --project={project_id}Files
- ATTRIBUTION.mdAdded by AutoGineer862 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md16.3 KiB
- references/adk-and-api-hub-discovery.md6.6 KiB
- references/attribution.md1.9 KiB
- references/mcp-limitations-and-troubleshooting.md10.7 KiB
- references/openapi-agent-tool-optimizer.md5.5 KiB
- references/openapi-v2-to-v3-mcp-migration.md17.2 KiB
- scripts/validate_mcp_openapi.pyScript22.0 KiB
references/openapi-v2-to-v3-mcp-migration.md
OpenAPI 2.0 to 3.x Migration and MCP Extension Reference
Why OpenAPI 3.x Is Required for MCP: Lines 11-18
OpenAPI 2.0 to 3.x Extension Mapping Table: Lines 20-34
Swagger 2.0 Construct Conversion Map: Lines 36-54
Configuration of x-google-api-management.mcp and x-google-mcp-tool: Lines 56-132
Tool Discovery Security (tools/list) vs Tool Calls (tools/call): Lines 134-140
How MCP tools/call Arguments Map to REST Requests: Lines 142-148
Complete Converted Example: Lines 150-251
Why OpenAPI 3.x Is Required for MCP
Model Context Protocol (MCP) support in Google Cloud API Gateway (Public Preview) requires an OpenAPI 3.x specification: OpenAPI 3.0.x or 3.1.x. The examples in this reference use openapi: 3.0.4.
NEVER add
x-google-api-management.mcporx-google-mcp-toolto an OpenAPI 2.0 (swagger: "2.0") specification. Rationale: MCP is not supported for OpenAPI 2.0, and the MCP extensions are defined only for OpenAPI 3.x.If an existing gateway runs an OpenAPI 2.0 specification, start from the spec file in the user's repository. If there is no file, find the active config ID with
gcloud api-gateway gateways describe {gateway_id} --location={region} --project={project_id} --format="value(apiConfig.basename())", and print its spec withgcloud api-gateway api-configs describe {config_id} --api={api_id} --project={project_id} --view=FULL --format=json | python3 -c 'import base64,json,sys; [print(base64.b64decode(d["document"]["contents"]).decode()) for d in json.load(sys.stdin)["openapiDocuments"]]'. Then convert it with the Swagger 2.0 Construct Conversion Map, and compare your result with the Complete Converted Example.
References: Supported OpenAPI versions and Modify a gateway to use OpenAPI 3.x
OpenAPI 2.0 to 3.x Extension Mapping Table
Standard OpenAPI 2.0-to-3.0 converters update standard OpenAPI fields (swagger -> openapi, securityDefinitions -> components.securitySchemes), but leave Google extensions in their legacy OpenAPI 2.0 form. You MUST manually migrate those extensions according to this table:
| Feature | OpenAPI 2.0 (swagger: "2.0") | OpenAPI 3.x | Required Structural Change |
|---|---|---|---|
| Backends | Inline x-google-backend object with snake_case fields (jwt_audience, path_translation, disable_auth) | Root x-google-api-management.backends.{backend_name} map with camelCase fields (jwtAudience, pathTranslation, disableAuth) + x-google-backend: {backend_name} string reference | Define named backends in x-google-api-management.backends (setting jwtAudience or disableAuth) and set x-google-backend to the string name. |
| JWT Auth | x-google-issuer, x-google-jwks_uri, x-google-audiences directly on the security scheme | x-google-auth: { issuer, jwksUri, audiences, jwtLocations } inside components.securitySchemes.{name} | Nest the JWT settings inside x-google-auth: x-google-issuer becomes issuer, x-google-jwks_uri becomes jwksUri, and the comma-separated x-google-audiences string becomes an audiences list. |
| Quotas | x-google-management arrays + x-google-quota: { metricCosts: { ... } } | x-google-api-management.metrics and quota.limits YAML maps + x-google-quota: { {metric_name}: {cost} } | Move metrics and limits into x-google-api-management as YAML maps (preserving exact metric names), and remove valueType, metricKind, and unit. Set each limit's values to a plain integer (no STANDARD key), and remove the metricCosts wrapper. |
| Endpoints (CORS) | x-google-endpoints | servers entry with x-google-endpoint: { allowCors: true } | Only one servers entry can carry x-google-endpoint. Remove the legacy name field. For basePath, see the Swagger 2.0 Construct Conversion Map. |
| Route Catch-All | x-google-allow (all or configured) | Unsupported in OpenAPI 3.x | Remove x-google-allow. API Gateway does not support it in OpenAPI 3.x. |
| API Name | x-google-api-name | x-google-api-management.apiName | Move x-google-api-name into x-google-api-management.apiName. |
| MCP Server | Unsupported | x-google-api-management.mcp (root) and x-google-mcp-tool (operation level) | Enable MCP globally or per operation. |
Reference: OpenAPI 3.x extensions in API Gateway
Swagger 2.0 Construct Conversion Map
Convert these standard Swagger 2.0 constructs as shown. Where a row says to ask the user, the choice belongs to the user.
| Swagger 2.0 construct | OpenAPI 3.x for API Gateway MCP |
|---|---|
basePath: /v2 (with or without host) | servers: [{url: "https://{managed_service}/v2", x-google-endpoint: {}}], where {managed_service} is gcloud api-gateway apis describe {api_id} --project={project_id} --format="value(managedService)". REST paths stay under /v2. MCP stays at https://{default_hostname}/mcp. |
Root x-google-backend: {address, path_translation} | Named backend under x-google-api-management.backends (address, pathTranslation) + root x-google-backend: {backend_name}. For a Cloud Run backend, set jwtAudience to the Cloud Run service URL. |
in: body parameter | requestBody.content.application/json.schema. |
definitions and #/definitions/{name} | components.schemas and #/components/schemas/{name}. |
securityDefinitions | components.securitySchemes. |
consumes / produces | Move the media types into requestBody.content and responses.content. Use application/json for tool operations: tools/call sends the request body as JSON in arguments.body, and tool responses are limited to UTF-8 text. |
in: formData (application/x-www-form-urlencoded) | requestBody with that media type. Recommendation: set x-google-mcp-tool: false, because MCP clients pass the request body as JSON in arguments.body. |
type: file (file upload) | requestBody with multipart/form-data and a type: string, format: binary property. Recommendation: set x-google-mcp-tool: false, because MCP tool arguments are JSON values. |
collectionFormat array parameter | API Gateway supports only primitive types in request parameters. Ask the user: keep the array for REST and set x-google-mcp-tool: false, or change the parameter to a primitive type (such as a comma-separated string) that the backend accepts. |
deprecated: true operation | Keep it for REST. Ask the user before you expose it as a tool, because agents can start to depend on it. |
Operation with only 4xx responses | Add the success response that the backend returns, with its JSON schema. Tools cannot return an empty body (HTTP 204). |
DELETE or other destructive operation | Ask the user before you expose it. If you expose it, warn in the tool description, because API Gateway does not emit destructiveHint annotations. |
No security | Add the scheme that the user asks for to x-google-api-management.mcp.tools-list.security. If it is a JWT scheme, also list it in the root security. See Complete Converted Example. |
Configuration of x-google-api-management.mcp and x-google-mcp-tool
You can enable MCP globally at the document root (x-google-api-management.mcp: true or object form) and customize or opt out individual operations using x-google-mcp-tool at the operation level.
Place
x-google-mcp-toolONLY on individual HTTP operation objects (get,post,put,patch,delete). NEVER placex-google-mcp-toolat the path item level. Rationale: API Gateway rejects specifications that declarex-google-mcp-toolat the path level.Every operation MUST have an
operationId, with or without MCP. Rationale: API Gateway rejects an API config that has an operation without anoperationId.Every exposed operation MUST also have a configured backend (
x-google-backendat root or operation level), a unique tool name that matches[A-Za-z0-9_.-]{1,128}(x-google-mcp-tool.name, or else theoperationId), and a non-empty description (x-google-mcp-tool.description, operationdescription, orsummary).Keep all MCP operations in one OpenAPI document. Rationale: If an API config has several OpenAPI documents, API Gateway serves the MCP tools of only one of them, and the tools of the other documents are missing without an error.
openapi: 3.0.4
info:
title: Orders API
version: 1.0.0
x-google-api-management:
mcp:
tools-list:
security:
agent_jwt: []
backends:
orders-backend:
address: https://{backend_service}-{hash}.a.run.app
jwtAudience: https://{backend_service}-{hash}.a.run.app
pathTranslation: APPEND_PATH_TO_ADDRESS
x-google-backend: orders-backend
components:
securitySchemes:
api_key:
type: apiKey
name: x-api-key
in: header
agent_jwt:
type: oauth2
flows:
implicit:
authorizationUrl: ""
scopes: {}
x-google-auth:
issuer: "https://accounts.google.com"
jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
audiences:
- "{oauth_client_id}"
security:
- api_key: []
agent_jwt: []
paths:
/v1/orders/{orderId}:
get:
operationId: getOrderStatus
summary: Get order status
description: Returns fulfillment status, carrier tracking number, and ETA for an order.
x-google-mcp-tool:
name: get_order_status
description: >-
Look up the fulfillment status, carrier tracking number, and delivery ETA for a customer order.
Call this tool when the user asks where an order is or needs the SKU before creating a return.
parameters:
- name: orderId
in: path
required: true
schema:
type: string
responses:
"200":
description: Order details
/v1/admin/orders/purge:
delete:
operationId: purgeOrders
summary: Purge archived orders
description: Administrative operation to purge archived order records.
x-google-mcp-tool: false
responses:
"200":
description: Purge statusReference: Configure Model Context Protocol
Tool Discovery Security (tools/list) vs Tool Calls (tools/call)
| MCP Method | Default Security | How to Configure | Critical Constraint |
|---|---|---|---|
initialize and notifications/initialized | Unauthenticated | No configuration | These protocol lifecycle methods are always unauthenticated. |
tools/list | Unauthenticated by default | x-google-api-management.mcp.tools-list.security (+ the same scheme in the root security list for a JWT scheme) | Must reference exactly one scheme in components.securitySchemes: a JWT scheme (oauth2 with x-google-auth) or an API key scheme (apiKey). For a JWT scheme, the root security list MUST also reference it (API Gateway rejects the config otherwise), and that root entry also requires the JWT on every REST operation without its own security. If the root list has an API key scheme, put the JWT in the same requirement object (AND), because API Gateway does not support alternative (OR) requirements with an API key. For an API key scheme, use in: header and name: x-api-key, because tools/list reads API keys only from the x-api-key header. Configuring mcp as an object also enables MCP globally for all eligible operations. |
tools/call | Inherits the operation's security requirement | Operation or root security block (apiKey and/or oauth2 JWT) | Shares the exact same authentication and x-google-quota allocation as direct REST calls to that operation. |
How MCP tools/call Arguments Map to REST Requests
When an MCP client invokes tools/call, API Gateway synthesizes the tool's inputSchema and maps params.arguments into the outbound HTTP REST request as follows:
Path and query parameters (
in: path,in: query): Become top-level properties insideparams.arguments, keyed by their exact OpenAPI parametername(for example,"arguments": {"orderId": "ORD-10042"}).JSON request body (
requestBody): Nested under a single top-level property namedbodyinsideparams.arguments(for example,"arguments": {"orderId": "ORD-10042", "body": {"itemSku": "SKU-1", "reason": "DEFECTIVE"}}). Passing body fields at the top level ofargumentswithout thebodywrapper fails validation with JSON-RPC error-32602(Invalid tool arguments).Header parameters (
in: header): Become top-level properties insideparams.argumentsand are injected as HTTP headers on the backend call. You cannot bind parameters to reserved system headers or headers starting withx-google-.
Complete Converted Example
This example is a Swagger 2.0 API with basePath: /v2, a root x-google-backend, a GET, a POST with a body, and a DELETE, converted for MCP. To list or call tools, a caller needs a valid Google ID token whose audience is {jwt_audience}.
openapi: 3.0.4
info:
title: Petstore API
version: 1.4.0
servers:
- url: https://{managed_service}/v2
x-google-endpoint: {}
x-google-api-management:
mcp:
tools-list:
security:
google_id_token: []
backends:
petstore-backend:
address: https://{backend_service}-{project_number}.{region}.run.app
jwtAudience: https://{backend_service}-{project_number}.{region}.run.app
pathTranslation: APPEND_PATH_TO_ADDRESS
x-google-backend: petstore-backend
security:
- google_id_token: []
components:
securitySchemes:
google_id_token:
type: oauth2
flows:
implicit:
authorizationUrl: ""
scopes: {}
x-google-auth:
issuer: https://accounts.google.com
jwksUri: https://www.googleapis.com/oauth2/v3/certs
audiences:
- "{jwt_audience}"
schemas:
Pet:
type: object
required: [name]
properties:
id: {type: integer, format: int64}
name: {type: string, description: 'Pet name, for example "Buddy".'}
status: {type: string, enum: [available, pending, sold]}
paths:
/pet/{petId}:
get:
operationId: getPetById
summary: Find pet by ID
x-google-mcp-tool:
name: get_pet
description: >-
Get one pet by its numeric ID. Use this when the user asks about a specific pet.
parameters:
- {name: petId, in: path, required: true, schema: {type: integer, format: int64}}
responses:
"200":
description: The pet
content:
application/json:
schema: {$ref: '#/components/schemas/Pet'}
delete:
operationId: deletePet
summary: Delete a pet
x-google-mcp-tool: false
parameters:
- {name: petId, in: path, required: true, schema: {type: integer, format: int64}}
responses:
"200":
description: The pet was deleted
/pet:
post:
operationId: addPet
summary: Add a new pet to the store
x-google-mcp-tool:
name: add_pet
description: >-
Add a new pet to the store catalog. Use this when the user wants to list a new pet for sale.
requestBody:
required: true
content:
application/json:
schema: {$ref: '#/components/schemas/Pet'}
responses:
"200":
description: The created pet
content:
application/json:
schema: {$ref: '#/components/schemas/Pet'}Values to fill in:
{managed_service}:gcloud api-gateway apis describe {api_id} --project={project_id} --format="value(managedService)".{jwt_audience}: the audience that callers request when they mint a token, such ashttps://{managed_service}. Do not use an IP address or an internal address, because API Gateway does not accept them in theaudclaim. A caller gets a matching token withgcloud auth print-identity-token --impersonate-service-account={caller_sa_email} --audiences={jwt_audience}. The token hasiss: https://accounts.google.comandaud: {jwt_audience}.API Gateway checks the token claims against the scheme. It does not check the IAM permissions that you granted to the caller's service account. A Google ID token scheme accepts every caller that can get a Google ID token with this audience. To accept only one service account, check the
emailclaim in the backend (API Gateway forwards the JWT payload in theX-Apigateway-Api-Userinfoheader), or use a self-signed JWT withissuerset to the service account email.
References:
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs an API key, Needs a command-line tool, Needs Python
Security
What our scanner noticed· Low risk
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/api-gateway-mcp-server · commit 2194d3b
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Google or Google.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway-mcp-server.zip