Protecting Tool Calls Does Not Hide the Tool Catalog
Google’s API Gateway preview can expose REST operations as MCP tools while reusing their existing access controls. Tool discovery is a separate decision: the catalog is open by default, even when calls require authentication. Teams need to check both what agents can see and what they can execute.

Summary
Google’s API Gateway preview can expose REST operations as MCP tools while reusing their existing access controls. Tool discovery is a separate decision: the catalog is open by default, even when calls require authentication. Teams need to check both what agents can see and what they can execute.
Key Updates
- A gateway can serve existing APIs as tools. Google’s September 24 announcement introduces Public Preview support for turning OpenAPI 3.x operations into remote MCP tools. The gateway translates tool calls into REST requests and applies the operation’s configured authentication, quotas and logging. OpenAPI 2.0 is not supported.
- Discovery needs its own authentication policy. The configuration guide says
tools/listis unauthenticated by default. Protecting it requires a JWT security scheme; API keys cannot secure discovery in this preview. Tool calls inherit the underlying operation’s requirements, which does not make an unprotected operation authenticated. - Enabling protection also affects exposure. Configuring discovery security through the MCP object enables all eligible operations as tools. Teams must explicitly opt out operations they do not want exposed. Choosing who can list tools and choosing which tools exist are separate configuration decisions.
Why It Matters
Reusing API controls can reduce duplicated integration work, but it does not settle every access decision. A protected action can still have a publicly visible name and input schema. Conversely, restricting discovery does not replace the checks required when that action runs.
Our July 7 edition examined the growing need for policy and visibility around agent workloads. This preview adds a narrower question: when an existing API becomes an agent tool, which controls carry over and which require a separate decision? It is a reason to evaluate the configuration, not evidence that the resulting workflow is safe by default.
Builder Takeaway
Test one non-production API before widening access.
Compare the intended tool list with the catalog returned to anonymous and authorized clients. Then test one harmless operation with valid, missing and invalid credentials. Confirm that discovery and execution each follow the intended policy, and that no unintended operation appears after enabling discovery authentication.
Sources
- Turn your REST APIs into MCP tools with Google Cloud API Gateway — Google Developers Blog, published September 24, 2026.
- Configure Model Context Protocol — Google Cloud documentation, updated September 24, 2026.
- Agent Workloads Are Getting Their Own Control Plane — Historical context · 2026-07-07 — Tech Radar, published July 7, 2026. Related past coverage; not evidence for Google’s implementation.
How strong is this signal for builders?
Signal feedback is stored anonymously and used to improve Tech Radar editorial quality.
If this was useful, we can send you the next one.
We follow changes in software, AI, and infrastructure—and explain what they mean for people building and running systems.
Sent by uniQubit · 1407 - 177 Nonquon Rd., Oshawa, ON L1G 3S2, Canada · info@uniqubit.ca
Privacy policy · Your confirmation email includes the controls to unsubscribe or change tracking.
Want more operational technology signals?
Follow uniQubit Tech Radar or contact uniQubit about a product, partnership, or operational software need.