Google API Gateway adds API-key authentication for MCP discovery

Google Cloud API Gateway can now require an API key when an AI client asks which MCP tools are available. The September 30 release notes announce API-key support for tools/list, adding an alternative to JWT authentication for tool discovery. The gateway’s Model Context Protocol capability remains in Preview.

The distinction matters for teams exposing operational APIs to assistants. Listing a tool is how a client learns that an operation exists and how to call it; executing the operation is a separate request. A team may want to restrict both, including when the tool only retrieves deployment or incident information.

Discovery and execution have separate authentication

Google’s MCP configuration documentation separates discovery from invocation. By default, tools/list is unauthenticated. The new option names one API-key security scheme in tools-list.security; clients supply the key through the x-api-key header. Query-parameter keys do not work for this method. Missing or invalid keys produce a JSON-RPC error without a tool list.

Calling a tool still uses the authentication requirements of its underlying OpenAPI operation. Initialization remains unauthenticated. Successful initialization or discovery therefore does not establish that a later operational action is authorized. For an SRE integrating an assistant, each of these results answers a different question about the connection.

What changes for an incident assistant

Consider a hypothetical assistant that can retrieve the latest deployment and request a rollback. An API key can protect its discovery request, allowing the client to obtain the tool descriptions through the newly supported path. The deployment lookup and rollback can then require different access under their own operation policies. Our automated-remediation guidance puts authorization at the operation that changes the target: authenticating to discover a rollback tool does not approve a rollback against the running service.

There is also a configuration consequence worth examining before deployment. Configuring MCP as an object enables it globally for eligible operations. Operations that should remain unavailable as tools need explicit x-google-mcp-tool: false settings. Review the resulting list against the APIs the assistant actually needs, rather than assuming that adding discovery authentication limits which operations appear.

For a gateway already using API keys, the release makes that credential type usable during discovery too. Verify a valid-key request returns the intended list and an invalid-key request does not, then test invocation against the operation’s own policy. If the integration requires named-user authorization or a production-supported MCP service, this Preview discovery option does not establish either. These are documentation-based checks to perform in your environment; no live gateway test is claimed here.