Skip to main content
Glama

get_cloud_savings

Read-only

Get the cloud savings model of the current project - or of one project, or the whole organisation, with project_id - the same recommendations the portal's Cost page and ankra cost savings show (scope says what was read). Returns, in the organisation's display currency (all *_cents figures are minor units of currency): total_monthly_savings_cents, counting each cluster once at its best measured or billed lever; estimated_monthly_savings_cents, what each cluster's best lever adds above that on estimates alone (quote it apart as an estimate, never as part of the total); recommendations, one lever per cluster with kind right_size_idle (unrequested node capacity: the compute cost of allocatable capacity no pod requests, of the binding resource per node group, with control-plane nodes and autoscaled groups left out, averaged over seven days - requests, never measured usage, so do not call it idle or unused), reduce_unallocated (run rate no namespace claims) or off_hours_schedule (a weekday 19:00-07:00 plus weekends stop for a cluster with no enabled power schedule whose purpose a person confirmed as non-production and that was measurably idle inside that window over the last 14 days), each with monthly_savings_cents, monthly_cost_cents, share_percent, confidence (measured: the metrics store's usage planned a ladder step; billed: an off-hours stop on billed compute; estimated: capacity less requests or the whole run rate with nothing observed, so say it is an estimate when you quote it) and the evidence it was computed from; breakdowns of the analysed clusters by billed component with their costliest namespaces; and the thresholds the model applied. A right_size_idle recommendation also carries its ladder: each node group onto the next smaller priced size of its class, one wave per step with the step's own monthly_savings_cents and the running total, and total_ladder_savings_cents (the step sum, never the unrequested-capacity ceiling); ladder_notes names every group left out and why, and evidence.metrics_state says present, absent (no usage series, so nothing can be sized) or unavailable (unknown). A right-size is a recommendation only when a step passed the plan-time fit and sizing checks: plan_required, when not null, means it needs a written maintenance plan (reasons production, stateful_volumes, zero_disruption_pdb, single_instance_database or cross_plan_family, with detail) and is in neither total, so never offer it as a one-click change; preflight, sizing and execution say what it was checked on and how it runs (in_place_resize or replace, nodes_at_once, canary waves). A right-size that offers no step is in withheld as kind right_size with reason no_safe_step, does_not_fit, peaks_exceed, no_headroom, inventory_stale or metrics_missing and its detail, and no money figure: quote the detail, not a saving. An off_hours_schedule's stop is scale_to_zero, which deletes the worker servers at the provider every night and creates new ones at the start, so anything on a worker's own disk is lost at every stop: its evidence.node_local_storage_state says present (node_local_pvc_count claims keep data on worker disks, node_local_pvc_names names up to 25), none, or unknown (the cluster inventory could not tell). On present or unknown, tell the user that data is lost nightly before offering the schedule. An offered off_hours_schedule's evidence also says why it was offered: environment_source (always person), environment_set_by and environment_set_at (who labelled the cluster and when), off_hours_window_days, off_hours_requests (verified ingress requests inside the stop window) and off_hours_busy_hours (hours its own workloads were busy there). withheld names every schedulable cluster the schedule was not offered for, with reason purpose_unconfirmed (nobody confirmed what the cluster is for: its environment label is a default), production (its label or criticality says production), off_hours_traffic (it served requests at night or at weekends), off_hours_workload (its workloads were busy then, such as nightly jobs) or activity_unmeasured (either signal could not be read, which is unknown, not idle), plus requests, busy_hours and window_days when they were measured; never propose stopping a withheld cluster, and for purpose_unconfirmed ask the user what the cluster is for. Only the biggest priced clusters are analysed (thresholds.analysed_cluster_limit): unanalysed_cluster_count and unreadable_clusters are unknown, not nothing to save; unanalysed_clusters names each left-out cluster with why (limit, budget, unreadable or no_breakdown), and since the analysed set is re-chosen on every read, a change in it is what moves the total between reads without anything being spent or saved. offline_clusters have an agent that has not checked in, so their inventory is stale and they are offered no recommendation: not nothing to save either. unpriced_clusters have never had a cost snapshot and stale_clusters have metering that stopped longer ago than thresholds.snapshot_stale_after_hours, so neither is in the totals. waste summarises the open cloud-waste findings; waste.available false means the scan could not be read, not that there is no waste. Read-only and estimate-based (list prices). ledger summarises the decision ledger's measured outcomes: measured_total_cents sums cost changes measured seven days after they ran (the cluster's run rate before the change minus its run rate at day seven, from cost snapshots, never an estimate), running_total_cents sums the expected savings of approved, running and still-verifying changes, and counts says how many decisions are pending, measured, unmeasured (coverage moved or no snapshots) or reverted; ledger.available false means the ledger could not be read, not that nothing was saved. Use get_cluster_cost on a cluster for its full per-namespace breakdown and propose_off_hours_schedule to act on an off_hours_schedule recommendation (it files the decision a person approves).

Input Schema

NameRequiredDescriptionDefault
project_idNoUUID of a project to read, or all for the whole organisation. Leave it out to read the project the conversation or token is in (the whole organisation while the organisation has no projects). list_projects has the ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / project_id
      Added value: +{
      +  "description": "UUID of a project to read, or all for the whole organisation. Leave it out to read the project the conversation or token is in (the whole organisation while the organisation has no projects). list_projects has the ids.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, and the description confirms and enriches that ('Read-only and estimate-based (list prices)'). It discloses far more than annotations could: that absent/unavailable/unreadable data means unknown rather than zero savings, that the analysed set is re-chosen each read and can move the total with nothing spent, that scale_to_zero destroys worker-local disk nightly, and what `ledger.available` / `waste.available` being false actually mean.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Almost every clause carries a genuine semantic distinction (measured vs estimated vs billed, withheld reasons, ladder vs ceiling), but it is delivered as one enormous unbroken paragraph with no headings or list structure, so scanability and front-loading suffer badly. Content is dense and relevant; delivery is not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full burden of describing return values — and it does, covering totals, currency units, recommendation kinds, ladder structure, withheld entries, thresholds, waste, and ledger. For a tool this complex, nothing an agent needs to call or report correctly appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already explains the default and the 'all' sentinel. The description still adds real meaning by framing the parameter as a scope selector ('or of one project, or the whole organisation, with project_id') and corroborating the default-project fallback.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb (get), a specific resource (cloud savings model), and the exact scope controls (current project, one project via project_id, or the whole organisation). It also ties the output to concrete equivalents the agent can anchor on (the portal Cost page and `ankra cost savings`).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing at both ends: 'Use get_cluster_cost on a cluster for its full per-namespace breakdown' and 'propose_off_hours_schedule to act on an off_hours_schedule recommendation'. It also states prohibitions ('never offer it as a one-click change', 'never propose stopping a withheld cluster') and conditional behaviours (ask the user what the cluster is for when purpose_unconfirmed).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources