Back to Tech Radar
security_planSep 25, 2026

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.

Editorial abstract cover for Protecting Tool Calls Does Not Hide the Tool Catalog, showing a google-cloud and api-gateway update as connected infrastructure signals

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/list is 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

    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.

    Occasional Tech Radar emails from uniQubit. Unsubscribe anytime.

    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.