Skip to main content
Glama

explain_cost_change

Read-onlyIdempotent

Explain a specific cost change: which timeline events line up with it, how strongly, and how much of the move Plutus could account for. Ask this about any point on a cost chart — it is not limited to anomalies the detector flagged (use list_anomalies for those; each already carries the same explanation).

RENDER explanation.sentences AS WRITTEN. They are generated under a strict discipline and are the only phrasing this data supports: Plutus reports temporal and dimensional evidence, never causation. Each candidate carries a claim of "coincides" (temporal proximity only — the common case), "consistent_with" (proximity plus a confirmed link between that event source and this cost entity) or "accounts_for" (a known dollar amount that matches the move). Do not upgrade one to another, do not say an event "caused" or "led to" the change, and do not merge several candidates into a single narrative.

Three separate numbers, never interchangeable: change_evidence is how sure we are a real change-point exists at all; attribution_completeness is what fraction of the move was localized to a specific part of the bill (a low value means "we do not know what this spend is yet", which is NOT the same as "nothing explains it"); p_cause is per candidate, and sums with p_unknown to 1. tier: "unknown" means we looked and found nothing that lines up — say that, rather than reaching for the top-ranked candidate anyway. Confidence is capped at 0.60 by design; there is no "high" tier today.

Body: dimension + value name the slice (e.g. service=AmazonEC2), optional cost_source_id narrows it, and exactly one of day or range says when. A range is narrowed to the single biggest-moving day inside it, reported as explained_day. Mirrors POST /api/accounts/:accountId/cost-changes/explain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNoYYYY-MM-DD — the day to explain
rangeNoHalf-open YYYY-MM-DD range; narrowed to its biggest-moving day
valueYesThe dimension value that moved, e.g. "AmazonEC2"
dimensionYesWhich dimension names the slice
cost_source_idNoNarrow to one cost source, e.g. "aws"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description richly discloses behavioral expectations: render explanation.sentences verbatim, never upgrade claim types, never imply causation, distinguish three confidence metrics, handle tier 'unknown' honestly, and understand the 0.60 confidence cap. This adds substantial context that annotations alone could not provide.

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

Conciseness5/5

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

Although long, every paragraph serves a distinct purpose: purpose/scoping, output rendering rules, metric definitions, and parameter semantics. The structure is front-loaded with the core action and each subsequent block earns its place by preventing misuse of a nuanced analytical tool.

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?

Given the absence of an output schema, the description compensates thoroughly by explaining the semantic meaning of the key returned fields (change_evidence, attribution_completeness, p_cause, tier, explained_day) and how to interpret them. It also grounds the tool in its API mirror, leaving no critical aspect of correct usage unexplained.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds critical semantic constraints: exactly one of day or range, range narrowing to the biggest-moving day with explained_day output, and concrete examples of dimension/value pairs. It also clarifies that cost_source_id is optional, which the schema only implies through non-required status.

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 description states a clear verb-resource pair ('Explain a specific cost change') and specifies exactly what the explanation covers: timeline event alignment, strength, and dollar attribution. It also differentiates from sibling list_anomalies by noting this tool works on any chart point and explicitly points to the alternative for anomaly-specific explanations.

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?

It explicitly tells the agent when to use this tool ('any point on a cost chart') and when not to, directing to list_anomalies for detector-flagged items. It further clarifies the 'exactly one of day or range' selection rule and how ranges are handled, giving practically complete guidance for invocation.

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