Skip to main content
Glama

list_savings_recommendations

Read-onlyIdempotent

List active cost-reduction recommendations for this account. Most come from each provider's own already-computed engine (AWS Cost Explorer, Azure Advisor, GCP Recommender); rows with source = plutus are computed by Plutus itself (rightsizing, and misconfiguration below). type is one of: terminate (an idle resource to shut down), modify (an overprovisioned one to downsize), commitment_savings_plan or commitment_reservation (a commitment worth buying — an AWS Savings Plan / Reserved Instance, Azure reservation or savings plan, or GCP committed use discount), or misconfiguration. Commitment rows have no current_instance_type/recommended_instance_type — they are a purchase, not an instance swap; their term, payment option, lookback window and hourly commitment are in detail. Only one term/payment/lookback variant per commitment is surfaced (AWS: 30-day lookback, 1-year, no upfront — Cost Explorer's own console default), so do not report these as the only commitment options available. Plutus also computes misconfiguration rows (source = plutus), the findings: a known costly setting found from billing lines (detail.scope = account) or an idle or orphaned resource found in the inventory (detail.scope = resource, with provider_resource_id). Their detail carries reason, fix, reference_url, confidence, spend_usd, impact_basis (upper_bound means the saving is a ceiling, at most that figure, not an estimate; say "up to". resource_cost means what the resource itself costs a month), impact_unknown (true means the saving cannot be estimated, so estimated_monthly_savings_cents of 0 is NOT a $0 saving), where (service, region, usage types) and verify (console links and manual steps to confirm and fix it). Triage them like any recommendation: dismiss, mark acted-on, or ticket. Mirrors GET /api/accounts/:accountId/savings-recommendations. Each recommendation carries the provider's own figure in its own currency; the total is in USD (stated in the response's currency field), since providers may bill in different ones. total_estimated_monthly_savings_cents is the firm total only: it leaves out upper_bound findings, which are reported separately as upper_bound_findings ({ count, max_monthly_cents }): say "N findings, up to $X/month", never add that into the total.

Input Schema

NameRequiredDescriptionDefault
typeNoOnly these recommendation types, comma-separated (for example "misconfiguration" for the findings)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / type
      Added value: +{
      +  "description": "Only these recommendation types, comma-separated (for example \"misconfiguration\" for the findings)",
      +  "maxLength": 300,
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent profile, yet the description adds substantial non-obvious behavior: which rows come from provider engines vs. Plutus, that commitment rows are purchases lacking instance-type fields, that only one term/payment variant is surfaced by design, and that `total_estimated_monthly_savings_cents` excludes `upper_bound` findings. It also spells out unit/currency semantics (per-provider currency vs. USD total). This is exactly the context annotations cannot convey.

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?

Purpose is front-loaded, but the body is a dense wall of unbroken prose in which `misconfiguration` and `source = plutus` are explained twice, and spending-reporting rules are interleaved with data-model facts. Content earns its place, but the structure makes it harder to scan than it needs to be.

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?

With no output schema and a single optional parameter, the description carries the full disclosure burden and does so: return shape, per-type field semantics, currency/total math, and interpretation caveats (`impact_unknown`, `upper_bound`). An agent has everything needed to call it and report results correctly.

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%, so baseline is 3, but the schema's `type` param has no enum and only a one-line description; the description supplies the full value vocabulary and flags that `misconfiguration` is the value returning Plutus findings. That is real added meaning beyond the structured field.

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?

States a specific verb and resource ("List active cost-reduction recommendations for this account") and then enumerates the exact row taxonomy (`terminate`, `modify`, commitment types, `misconfiguration`) plus their provenance. An agent can tell this apart from `list_tag_recommendations` or `list_commitment_expirations` by the explicit source/type inventory.

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

Usage Guidelines3/5

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

There is useful in-tool usage guidance ("for the findings, use type=misconfiguration") and downstream handling ("Triage them like any recommendation: dismiss, mark acted-on, or ticket"), but no explicit when-to-use-this-vs-sibling routing, even though `list_tag_recommendations` and `list_commitment_expirations` sit right next to it. Usage is implied by the content rather than declared.

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