Google Cloud API Gateway MCP: A Founder’s Launch Gate for Agent Tools

On September 24, Google Cloud announced public-preview MCP support in API Gateway. A team with an OpenAPI 3.x REST service can annotate its specification and expose eligible operations as tools at a gateway /mcp endpoint. The gateway translates a tools/call request into the existing REST request. For an AI app builder, that removes a piece of integration work, but it also makes an existing product capability available through a new decision maker: an agent.

The launch question is therefore more specific than “Can our agent connect?” It is which customer actions should be discoverable, invocable, and reversible, by whom, under which user promise? Google says tools/list is unauthenticated by default, while tools/call follows the underlying REST operation's authentication. Its documentation also says that configuring authenticated discovery as an object enables MCP globally for eligible operations unless they are explicitly opted out. A team that thinks it merely hid a directory could widen the tool catalog. These are product release decisions, even if engineers implement the configuration.

This guide is for nontechnical founders and small product teams adding agents to an existing app, especially one with account data or actions such as refunds, bookings, messages, and record changes. It provides a concrete release receipt, an order-support scenario, failure drills, and go/no-go rules. It does not claim the preview is insecure by itself, nor that passing the checklist proves an agent safe in every context.

What shipped, and what did not

Google's announcement describes an API Gateway feature in public preview, not a new general-purpose agent platform. You annotate an OpenAPI 3.0 or 3.1 document, deploy an API config, and connect an MCP client to /mcp. The gateway supports tool discovery and tool invocation. Each call is translated back to an existing REST operation, so that operation's configured API key or JWT rule, quota, and logging path still matter. This is valuable if a small team already has a reliable API and wants an agent to use it without maintaining a separate MCP server.

The configuration documentation defines meaningful boundaries. Only GET, POST, PUT, PATCH, and DELETE operations can be exposed. Every exposed operation needs a backend and a nonempty description. An operation can be renamed or excluded individually. The preview limitations include no MCP resources or prompts, no response streaming, no emitted readOnlyHint or destructiveHint annotations, no support for operations with empty responses such as HTTP 204, and a possible loss of detail for deeply nested schemas in discovery. MCP and model routing cannot share one API config. These limits can affect the product flow: an agent may see an incomplete argument shape, or a “successful” empty response may not be offered as a tool at all.

A preview label is a procurement and release input. Google's documentation says this feature falls under its pre-GA terms and may have limited support. A founder should ask whether the product can tolerate changed behavior, what an alternative path costs, and who can turn the tool exposure off. The announcement establishes a capability; it does not establish that a particular app's permissions, copy, support process, and customer outcomes have been validated.

Three terms the product team must keep separate

Tool discovery means an MCP client asks for the available tool names, descriptions, and argument schemas through tools/list. A catalog entry can tell an agent what it might try. It can also reveal the shape of an internal capability to someone who should not know it exists. The MCP tool specification defines discovery and invocation as distinct requests and notes that tools are often model-controlled. Tool invocation means a client sends tools/call with a selected name and arguments. In this gateway preview, that becomes a REST call. The gateway's authentication check can reject an unauthenticated call, but a successful check does not answer whether the customer wanted the action, whether a support agent used the right account, or whether the outcome was communicated truthfully. Authorization is necessary; it is not the whole product contract. User consent and business authorization are the app's decision that this user, in this moment, may cause this effect. A valid API credential might belong to a service account with broader scope than the customer. A natural-language instruction might be ambiguous. The OWASP guidance on excessive agency recommends downstream permission checks in the user's context and human approval for high-impact actions. The MCP specification likewise recommends interfaces that make tool exposure visible and allow people to deny invocation. Those are design principles, not a guarantee supplied by a gateway toggle.

The useful mental model is three questions: Can the agent see this operation? Can the credential execute it? Should the product allow this particular execution? Record separate answers. “The API already has auth” only answers part of the second question.

Start with a customer job, then reduce the catalog

Imagine a small order-support app. Customers ask, “Where is my parcel?” and sometimes, “Can you change the delivery address?” The existing API includes getOrderStatus, listOrders, changeAddress, cancelOrder, issueRefund, and an internal exportOrders operation. The fastest technical route could expose all eligible methods. The smallest useful product route exposes only order status to the first pilot, scoped to the signed-in customer's own order.

Write a one-sentence job before naming tools: “A signed-in customer can ask for the current shipping status of one order they own.” Then name a non-goal: “The assistant cannot change fulfillment state or reveal another customer's details.” This sounds elementary, but it gives an engineer an exclusion test and gives a reviewer a reason to reject extra operations. A large tool catalog increases both selection ambiguity and accidental access paths. The Google configuration guide permits per-operation inclusion or explicit opt-out; use that capability deliberately.

Do not copy a REST route name into the model-facing description and call it finished. A tool description is selection guidance. “Get order” may encourage the agent to call it for billing disputes, shipment changes, or someone else's order. A better description says the job, data returned, and when not to use it. For example: “Look up delivery status and ETA for one order belonging to the authenticated customer; do not use for refunds or address changes.” The backend must still enforce ownership. A description can steer a model, but it cannot enforce an account boundary.

For the first release, prefer a read operation whose result is useful without exposing sensitive fields. If the REST response includes address, phone, payment reference, or internal fraud notes, make a product-specific response with the minimum fields before exposing it. Tool output enters the agent's working context and may appear in explanations or logs. The OWASP MCP security cheat sheet identifies over-sharing and confused-deputy behavior as separate risks from a bare authentication failure.

The discovery switch has a surprising consequence

Google states in both its announcement and docs that tools/list is unauthenticated by default. That does not grant permission to invoke protected REST operations, but it can publish tool names and input schemas. A public catalog called issue_refund, export_all_orders, or override_risk_hold tells outsiders something about your internal system even when calls fail. The correct exposure choice depends on the application; for a private customer-support product, anonymous discovery is rarely a necessary feature.

The less obvious point is the configuration shape. The docs say that setting x-google-api-management.mcp to an object to configure tools-list.security also enables MCP globally for all eligible operations. If your team first used per-operation tool selection, adding JWT protection without reviewing the entire resulting catalog can accidentally widen discovery. Operations you do not want exposed must be opted out with x-google-mcp-tool: false. This is a documented behavior, not evidence that Google deployed a vulnerable default for every customer: exposure still depends on the specification and deployed config.

Ask for a before-and-after catalog diff at release time. The artifact should list each discovered tool, input schema, intended audience, owning REST operation, and whether it is read or write. Test tools/list with no token, an expired token, the wrong audience, a valid customer token, and a valid internal token. Google's JWT guide explains issuer, audience, subject, issue and expiry claims; the MCP documentation says discovery protection must use a single JWT scheme, not an API key. The team should preserve the raw responses and status codes, not merely a screenshot saying “auth works.”

Invocation needs a per-user contract

Google says tools/call uses the authentication policy on the REST operation it maps to. That is a helpful consistency property: an MCP call should not silently take a different gateway policy path. Yet the resulting request still needs application-level authorization. In the order example, a customer can have a valid token and supply another person's orderId. A service token might be permitted to read every order for internal support. The release check is whether the backend establishes the user-to-order relationship on every call, independent of what the agent claims in the prompt.

A useful permission table has four columns: actor, operation, record scope, and required confirmation. For get_order_status, a signed-in customer may read only their own order, and no extra confirmation is needed. For change_address, a verified customer may modify an eligible order only before fulfillment, after the app displays the exact old and new address. For issue_refund, a support employee might propose a refund but a second authorized person or controlled workflow approves it. These are example product policies, not capabilities Google says its gateway will implement for you.

Protect against credential confusion. If the agent calls all tools using one broad backend identity, “customer A asks about order B” can become a data leak despite valid gateway authentication. The MCP authorization specification discusses authorization at the protocol boundary, while the OWASP excessive-agency guidance recommends enforcing the customer's scope downstream. Map the end user into the backend decision or use a narrowly scoped credential. Test with two real test accounts and an unrelated order; if the forbidden cross-account call succeeds, the agent feature does not ship.

Separate answers from actions in the user experience

An answer such as “Your parcel is in transit” and an action such as “I changed your address” have different failure costs. The customer interface should visibly distinguish them. For a read result, show the source state and its time or freshness where available. For a write, show the intended target, exact proposed change, and who can cancel it before submission. After submission, show a receipt from the system of record. Do not let the model's fluent sentence serve as the only proof that a write occurred.

A tool may return an error after the backend committed an action, or the client may retry after a timeout. The user's experience is then ambiguous: did the address change once, twice, or not at all? For consequential writes, engineering should provide idempotency keys or an equivalent duplicate-prevention rule, an operation identifier, and a way to read the authoritative final state. The founder-level acceptance criterion is simple: a user must be able to know what happened, and support must be able to reconstruct it. This is an application design requirement inferred from the side effects of REST tools, not a feature automatically supplied by MCP.

The MCP tool interaction guidance says applications should show which tools are exposed, indicate invocations, and present confirmation prompts. The protocol does not prescribe the exact UI. Design a confirmation screen around the concrete effect, not around the tool name. “Approve change_address” is harder to understand than “Change delivery address for order A-1042 from X to Y.” Provide a normal path for “No” and a support path if the post-action state is uncertain.

A release receipt the founder can actually review

Use one compact record per tool. It should fit in a product review, with technical evidence linked rather than buried in a deployment chat. The following is a reusable template; its values are illustrative, not a report about a live YBuild or Google customer.

Field	Example acceptance evidence for `get_order_status`
Customer job	Signed-in owner asks for shipping status of one order
Catalog decision	Only `get_order_status` appears in the customer MCP catalog
Discovery proof	Anonymous, expired, and wrong-audience `tools/list` denied; valid token lists the approved tool
Invocation proof	Own order succeeds; other customer's order and nonexistent ID are denied without data
Data returned	Status, carrier, ETA, update time; no address, phone, payment, or internal notes
User presentation	Assistant says when status was updated and offers ordinary support escalation
Failure behavior	Timeout and malformed result do not become a fabricated delivery claim
Operations	Owner, alerts, quota, rollback config, and support route recorded
Approval	Product owner and security/engineering reviewer sign the exact config version

A second column of the actual review should hold links to the deployed OpenAPI config, recorded test cases, and screenshot or trace of the user flow. A “pass” without a version is fragile because a later spec change can add a new operation. The Google MCP configuration guide makes clear that global enablement and per-operation overrides are both possible, so every deployment should compare the effective catalog, not only the source diff. The MCP specification also allows tool-list changes; clients may need to refresh what they know. The release receipt should identify what was actually discoverable to the customer at deployment time.

For a write tool, add rows for user confirmation, idempotency, reversal, partial failure, and a final system-of-record check. If a team cannot show those rows, keep that operation outside the catalog. This is a narrow launch gate, not a demand to perfect the entire app before allowing one useful read-only feature.

Run failure drills before the pilot

The first drill is anonymous discovery. Ask the team to call tools/list without credentials against the deployed endpoint. If it returns the private catalog, do not rely on “but calls are protected.” Decide whether the catalog itself is public by design. If it is private, set JWT discovery protection and verify it. The official docs explicitly recommend this for production.

The second is catalog expansion. Add a harmless eligible operation to a staging OpenAPI spec, deploy the same security configuration, and see whether it appears. If a global MCP object exposes it, the team must prove explicit opt-outs or switch to a deliberate catalog-management process. This drill guards against future API growth, not only today's file.

The third is wrong customer, right credential. Sign in as customer A and request customer B's order ID. The expected result is a denial with no details about whether B's order exists if that distinction leaks private information. Repeat with a support credential to ensure the support workflow's broader rights do not get accidentally used on the customer path.

The fourth is description pressure. Ask the agent for a refund, an address change, and a status lookup in natural language. It should use the status tool only for the last job. A mistaken call may be harmless while the backend is read-only, but it signals that tool descriptions or the app's instruction boundary need revision. The OWASP MCP cheat sheet warns that tool descriptions and outputs are behavior-shaping surfaces; they deserve review as product text.

The fifth is bad data and uncertainty. Return an old ETA, a missing carrier, a timeout, and a response containing text that instructs the agent to ignore previous rules. The assistant should treat the response as data, avoid a confident false claim, and offer a human route. OWASP's MCP Top 10 identifies tool poisoning and contextual prompt injection as risks. A successful gateway auth check does not sanitize a backend's content.

The sixth is rollout and reversal. Turn the tool off in staging, confirm it disappears from discovery, and confirm clients do not continue invoking a cached copy. Measure how long the change takes to reach a real test client. If the answer is unknown, do not promise instant revocation to customers or support. Rollback is a customer capability only when its end-to-end effect has been observed.

Measure the pilot without mistaking traffic for value

Google's monitoring documentation says API Gateway records request and response logs and exposes latency, traffic, and errors. That gives an operational baseline, but a rising call count is not proof customers got useful answers. Instrument the product path as well: request intent, tool chosen, auth result, customer-visible outcome, correction, escalation, and whether the customer completed the original job. Avoid logging full private responses merely to improve a dashboard.

A short pilot dashboard can have four groups. Access: anonymous discovery attempts, denied calls, cross-account test outcomes. Reliability: latency, timeouts, malformed responses, duplicate writes. User value: resolved status inquiries, handoff rate, user corrections. Scope: catalog additions, description changes, permission exceptions. Review examples behind each rate. If a number improves because the assistant gives confident but stale status, it is not a real win.

Quotas need the same care. Google's quota overview says quotas are defined in an API config but apply to the whole API, and newer configs can affect other deployed gateways. A change meant to protect an agent pilot may therefore affect ordinary app clients. Agree on a traffic budget, test limit behavior, and watch both MCP and REST users. The launch owner should know whom to contact when the agent consumes shared capacity during a spike.

When this route fits, and when to wait

This route fits a team with a maintained OpenAPI 3.x service, clear per-operation authentication, a small catalog of high-value jobs, and someone who can inspect the effective deployed config. It is particularly plausible for low-risk read tasks where a human-facing interface can show uncertainty and a support fallback. It is less attractive when the product depends on MCP resources or prompts, streamed responses, deeply nested schemas whose discovered shape matters, empty-body operations, or model routing in the same config. Those are documented preview limits, not hypothetical objections.

Wait on write actions if ownership is checked only in the prompt, if a service credential bypasses user scope, if customer approval cannot name the exact effect, or if retries can duplicate side effects. Wait on any launch if the team cannot retrieve the effective tool catalog or reverse exposure during an incident. A separate MCP server or a different gateway may be appropriate in some cases, but that choice also needs an equivalent product acceptance test. “No separate server” saves integration work; it does not transfer responsibility for the customer promise.

The concrete decision today is modest: choose one customer job, expose the minimum operation set, test both discovery and invocation against real roles, and keep write capabilities outside the first pilot until their confirmation and recovery paths are proven. Google Cloud's preview makes REST-to-MCP connection easier. The product advantage comes from knowing exactly what the agent is allowed to do and being able to show the customer what happened.

References