Google Cloud App Optimize MCP: Guardrails for Cost Analysis Agents

Google Cloud put the App Optimize API remote Model Context Protocol (MCP) server into preview on October 7, 2026. It lets an AI application create and read reports that combine Google Cloud cost data with CPU and memory utilization for a project or an App Hub application.

That sounds like a convenient FinOps assistant. It is also a new path from a model to billing and monitoring data. Naming expensive resources is the easy part. The harder test is tracing each answer to a defined scope, an authorised identity and a report whose time range and metric semantics are understood.

The safest first use is read-oriented analysis with a narrow project boundary. Keep remediation outside the workflow until the team has measured answer quality and reviewed how sensitive cost data moves through the client, model, logs and MCP server.

What the preview exposes

The App Optimize MCP reference lists tools to create, inspect, list, read and delete cost reports, plus a tool to poll report-generation operations. The endpoint is https://appoptimize.googleapis.com/mcp.

The server is designed for questions such as which products or resources cost the most, which resources appear underused, and how much an App Hub application cost over a period. Unlike a general query against a billing export, App Optimize joins cost information with supported utilization metrics.

Report design changes the agent's control flow. Cost-only reports usually complete faster than reports that pull utilization from Cloud Monitoring. Google says cost-only reports typically finish in under a minute, while reports containing utilization metrics can take around nine to ten minutes or longer. An agent must poll the original operation rather than assume a slow response has failed and create duplicate reports.

Saved reports expire after 24 hours. Their definitions are immutable, so changing the scope, dimensions, metrics or filter means creating a new report. Empty output can also be valid: a new project, an idle scope or a filter with no matching records may return columns without rows.

These behaviours belong in the workflow design. Otherwise, an impatient agent may retry valid work, compare differently configured reports, or present an empty result as a system error.

Put the report scope in the question

Each report has one scope: either a Google Cloud project or an App Hub application. A report can be stored in one project while analysing data from another, provided the calling identity has the required permissions on the relevant resources.

Do not let the agent infer scope from whichever project happens to be configured in its client. Make the intended project or application part of the request and confirmation step. For example:

Analyse cost and utilization for payments-production from October 1 through October 7. Group by product and resource type. Do not query other projects.

The agent should repeat the resolved scope, time range, grouping and requested metrics before it creates the report. That short confirmation gives a reviewer something concrete to compare with the resulting configuration.

For organisations operating across the US, UK, Saudi Arabia and UAE, do not assume the location of the analyst or the workload determines where MCP traffic and model processing occur. Review the MCP endpoint, AI client, model provider, Model Armor configuration and log destinations as one data path. Google's documentation notes that Model Armor availability and routing can vary by region, which can affect data-residency decisions.

Use a separate identity for the agent

Google recommends a separate identity for agents using MCP tools. That identity makes access easier to constrain and its activity easier to distinguish from a person's work.

The App Optimize setup guide lists several permission layers:

• roles/mcp.toolUser on the project where the MCP server is used;
• App Optimize access to create or read report resources;
• billing.resourceCosts.get for cost data;
• roles/monitoring.viewer for utilization data; and
• App Hub viewing access when the scope is an App Hub application.

Grant only the data access required for the pilot. A cost-only workflow does not need monitoring access. A project-level pilot should not inherit organisation-wide billing visibility merely because that role is easier to assign.

The MCP server uses OAuth 2.0 and IAM and does not accept API keys for authentication. Keep the client credential outside prompts and model-visible context. If a tool call returns PERMISSION_DENIED, surface the missing permission for an administrator to review; do not let the agent attempt to modify IAM or repeatedly probe adjacent projects.

Define the metric contract before asking for savings

An answer such as “this VM is underutilized” is incomplete without the metric and interval behind it. App Optimize exposes mean and p95 CPU and memory utilization, along with usage and allocation measures.

Mean utilization alone can misclassify a workload with periodic peaks. Low mean with high p95 may indicate a bursty service that still needs its provisioned capacity. Low mean and low p95 across a representative interval is stronger evidence of idle capacity, but it is still not a change approval.

The same care applies to cost. App Optimize reports usage cost for the selected period, not the final invoice total. Time dimensions use Pacific Time and respect daylight-saving changes. If a request says “last month,” the workflow should calculate explicit Pacific Time boundaries rather than rely on UTC midnight or an ambiguous default. Without a time filter, the default is the seven days ending at the previous Pacific Time midnight.

Use a simple evidence contract for every recommendation:

| Field | What the agent must show | |---|---| | Scope | Exact project or App Hub application | | Interval | Start and end timestamps, including offset | | Grouping | Product, resource, resource type, location or other dimensions | | Metrics | Cost plus the utilization or allocation measures used | | Result state | Completed, validly empty, expired or failed | | Caveat | Missing metrics, unsupported resource type or unusual peaks | | Next step | A reversible investigation, not an automatic production change |

This contract turns a plausible narrative into a reviewable analysis.

Separate observation from remediation

The current MCP tools operate on report resources; they do not resize a VM or change a production deployment. Keep that boundary visible. An optimisation workflow can identify candidates and assemble evidence, then hand a proposed change to the system that already owns infrastructure review and deployment.

For the first pilot, require a human to approve any recommendation before it becomes a ticket or code change. Verify the finding against the relevant service dashboard and workload owner. Test the proposed adjustment in the normal delivery path, with rollback and service-level checks.

This separation also limits prompt-injection risk. A report row or resource label should be treated as data, not as an instruction. The agent must not follow commands embedded in names, labels or other retrieved fields. Google's MCP security guidance recommends distinct agent identities, least privilege and careful control of tool calls; those controls still matter when the tools are read-oriented.

A practical pilot plan

Choose one non-critical project with known cost patterns and enough activity to produce useful reports. Then run a fixed set of questions that the FinOps or platform team can answer independently:

1. Rank products by usage cost for an explicit seven-day period.
2. Identify high-cost compute resources with both low mean and low p95 utilization.
3. Compare the current period with the preceding period using separate, equivalently configured reports.
4. Explain every empty or null value without retrying it as an error.
5. Reproduce the same result from the saved report configuration and returned rows.

Score the agent on scope accuracy, metric choice, calculation accuracy, evidence completeness and the rate of unsupported recommendations. Include latency and duplicate-report creation in the evaluation because utilization reports are intentionally asynchronous.

Log the tool name, resolved scope, report configuration, operation identifier and final status. Be deliberate about payload logging: Google's documentation warns that Model Armor logging can capture complete payloads. Cost and resource data may be commercially sensitive even when it contains no customer records.

Decide what the pilot earned

A successful pilot does not prove that an agent should control cloud resources. It shows whether the team can obtain repeatable cost analysis through a governed interface.

Expand only when the agent consistently selects the correct scope and interval, handles asynchronous and empty results correctly, and produces recommendations that reviewers can verify. Keep production changes behind the same pull request, approval and deployment controls used for human-authored infrastructure.

For related design patterns, see Bayseian's guide to governing Gemini Enterprise agents, the Google Cloud API Gateway MCP review checklist, and our framework for choosing workflows that deserve an agent. If you are designing a governed FinOps or MCP pilot, talk to Bayseian about the identity, evidence and evaluation boundaries before connecting it to production data.

Sources

• Google Cloud release notes, “The App Optimize API remote MCP server is in Preview,” October 7, 2026.
• Google Cloud, “Use the App Optimize API remote MCP server,” updated October 9, 2026.
• Google Cloud, “MCP Reference: appoptimize.googleapis.com,” updated October 9, 2026.
• Google Cloud, “About cost and utilization reports,” accessed October 13, 2026.
• Google Cloud, “AI security and safety,” accessed October 13, 2026.