Skip to main content
Glama

list_anomalies

Read-onlyIdempotent

List detected cost anomalies for this account over a trailing lookback window — the real output of Plutus's nightly anomaly detector (severity, baseline vs. current spend, and what drove a tag-level spike), not something recomputed here from raw spend. Prefer this over eyeballing query_costs for "did anything spike" — the detector already accounts for day-of-week baselines and an absolute-dollar noise floor that a naive comparison would miss or over-trigger on.

Capped at 200 rows, most recent first; days (default 30, max 90) bounds the lookback. kind is "service" or "tag". current_cents/baseline_cents/delta_cents are the USD base. suppressed: true means a human has marked this exact signature (provider+service, or tag_key+tag_value) as expected — mention it but do not lead with it as a live problem. driven_by is null when driver attribution was not measured for this anomaly and [] when it WAS measured and found no dominant driver — those mean different things. Its entries differ by anomaly kind: a tag anomaly's entries are service-shaped (service/cost_source_id/share_pct — the services that fed the tag_value's spike); a service anomaly's entries, when the account has resource-grain detection enabled, are resource-shaped (resource_id/resource_type/share_pct — the specific resources, e.g. an EC2 instance or Lambda function, that drove that service's spike). Report a resource entry as a decomposition of the same service anomaly, never as a separate anomaly of its own. correlated_events is the service-anomaly counterpart: deploy/incident/release activity that was unusual (above the account's own baseline rate) in the 2-day window ending on the spike day, ranked by share of that excess. Same null-vs-[] distinction — null is "not measured" (a tag anomaly, or a row recorded before this shipped), [] is "measured and nothing was unusual". It is account-scoped and temporal: it does NOT claim the event caused this particular service's spend to rise, so report it as activity that lines up, never as a cause. notified: false means this anomaly was recorded but withheld from alerting because its tag_key was already at the per-run notify cap. Mirrors GET /api/accounts/:accountId/anomalies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoTrailing lookback window in days (default: 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations. It discloses the 200-row cap, most-recent-first ordering, the default/max of the lookback window, the semantics of suppressed rows, and — critically — the null-vs-[] distinction for driven_by and correlated_events, plus what null vs [] means for notified-withheld rows. It also explicitly disclaims causation for correlated_events, which prevents a likely agent error.

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?

Dense and front-loaded, but it is a wall of text with many field-level notes packed into a single block. The information is valuable, yet the structure is a run-on rather than crisply partitioned; a bulleted breakdown of the response fields would be easier to parse. It earns most of its length but could be tightened.

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?

For a list tool with no output schema, the description lays out the shape of the result (severity, baseline vs. current, drivers, correlated events) and all the subtle field semantics an agent needs in order to report results correctly. Account-scoping, ordering, and the cap are all present. Nothing material is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the single 'days' parameter is documented in the schema, so the baseline is 3. The description does add the default (30) and max (90) in prose, but that duplicates schema information rather than extending it.

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 specific verb+resource ('List detected cost anomalies') and immediately distinguishes itself from a sibling ('Prefer this over eyeballing query_costs'). It also clarifies the data source ('the real output of Plutus's nightly anomaly detector ... not something recomputed here from raw spend'), leaving no ambiguity about what a caller gets.

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 guidance: use this over query_costs when asking 'did anything spike', with the reason (day-of-week baselines and an absolute-dollar noise floor). It also tells the agent what to do with edge-case rows ('mention it but do not lead with it as a live problem' for suppressed, and 'report it as a decomposition of the same service anomaly, never as a separate anomaly of its own' for resource-shaped drivers).

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