Skip to main content
Glama

query_costs

Read-onlyIdempotent

Query time-bucketed spend for this account, optionally broken down by a dimension (service, region, linked_account, usage_type, operation, or identity) or by a custom cost-allocation tag (see list_cost_tags), and filtered by dimension values. identity is per-actor spend (e.g. an OpenAI or Anthropic api_key_id) where a provider's cost/usage API can group by it; not every provider populates it. Mirrors the GET /api/analytics endpoint used by the Plutus dashboard charts. All amounts are in USD, converted from each provider's own billing currency at the rate in effect on the day of the charge; the response states this in its currency field.

A row carries cost_basis only when its cost figure is an estimate rather than a real invoiced charge — e.g. Anthropic's identity-grain rows, priced from Anthropic's own published per-token rates because Anthropic's cost API has no per-key breakdown at all. Absent (null) cost_basis means the figure is invoiced. Always qualify an estimated figure as such when relaying it — do not present it with the same confidence as an invoiced one.

Where a provider reports usage alongside cost, a row also carries quantity and its unit (e.g. tokens, GB-month), plus a derived cost_per_unit in that same USD base. Always read cost_per_unit together with cost_per_unit_label, which names the denominator it is quoted against: token costs are quoted per 1,000 tokens ("per 1k tokens", cost_per_unit_scale: 1000), NOT per single token. All four fields are null when the provider reports no usage, and also when the rows behind a group carry more than one unit — a total mixing tokens and GB-month is not a quantity, so none is given.

The response also carries coverage.complete_through: cost data for the newest periods often has not landed yet (it arrives hours-to-a-day after the period it covers), so rows may end before end_date without that being a gap in spend — the newest period(s) simply aren't complete yet. coverage.lagging_sources, when non-empty, names a cost source that is behind or has stopped reporting; recent periods will under-count its spend. Unlike query_unit_costs, rows is NOT truncated to the horizon here — treat complete_through as a caveat on the newest bucket(s), not evidence anything is missing from the rows themselves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tag_keyNoRequired when breakdown_by is "tag" — one of the tag_keys returned by list_cost_tags
end_dateNoISO-8601 end of the date range (exclusive)
group_byNoTime bucket size (default: day)
start_dateNoISO-8601 start of the date range (inclusive)
cost_metricNoWhich cost figure to sum (default: "billed"). "amortized" spreads prepaid commitments (AWS Reserved Instances/Savings Plans, Azure reservations) across the term they cover instead of showing the full charge on the day it was billed. Only AWS, FOCUS and Azure sources ever differ from billed — every other provider writes amortized equal to billed, and that is the true figure for a SaaS subscription or LLM API, not a fallback. Amortized data only exists from 2026-08-04 onward and cannot be backfilled; rows before that date are billed-as-amortized regardless of which value is passed here. Not supported by get_cost_entries.
breakdown_byNoDimension to break spend down by, or "tag" to break down by a virtual cost-allocation tag_key (see list_cost_tags) — requires tag_key.
filter_regionNoRestrict to these region values
filter_clusterNoRestrict to these cluster values
filter_serviceNoRestrict to these service values
cost_source_idsNoRestrict to these provider ids (defaults to all enabled providers)
filter_identityNoRestrict to these identity values
filter_workloadNoRestrict to these workload values
filter_namespaceNoRestrict to these namespace values
filter_operationNoRestrict to these operation values
filter_usage_typeNoRestrict to these usage_type values
filter_resource_idNoRestrict to these resource_id values
filter_linked_accountNoRestrict to these linked_account values
secondary_breakdown_byNoA second dimension to break spend down by simultaneously with breakdown_by. Only pairs that some provider actually stores together on the same row are supported — e.g. (service, region), (service, linked_account), (usage_type, operation), and Kubernetes' (namespace, workload) — any other pair returns an error. Not applicable when breakdown_by is "tag".

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only and idempotent behavior, so the description is free to add critical behavioral nuance: estimate-vs-invoiced semantics via cost_basis, quantity/unit/cost_per_unit caveats, currency conversion, coverage.complete_through lag, and lagging_sources. These go well beyond the structured annotations and materially change how a caller should interpret results.

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?

The description is long but every paragraph earns its place by addressing a distinct interpretation risk: what the tool returns, how to treat estimated costs, and how to interpret incomplete coverage. It is front-loaded with the core action and then layers caveats in a logical order without repetition.

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 tool with 18 parameters, no output schema, and a complex cost-reporting domain, the description is exceptionally complete. It explains currency, estimate status, unit semantics, coverage lag, differences from sibling tools, and unsupported combinations. An agent has enough context to invoke it correctly and interpret results responsibly.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful parameter-level meaning, especially around cost_metric: amortized only differs for AWS/FOCUS/Azure, is unavailable before 2026-08-04, and cannot be backfilled. It also clarifies secondary_breakdown_by pairing constraints and the tag_key relationship, which the schema alone does not fully convey.

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?

Opens with a specific verb and resource: 'Query time-bucketed spend for this account,' and immediately distinguishes itself from related tools by naming the dimensions it can break down by, the tag path, and the mirrored endpoint. It also contrasts behavior with query_unit_costs and get_cost_entries, so an agent can tell sibling tools apart.

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?

Provides explicit when-to-use and when-not-to-use guidance: it references list_cost_tags for tag keys, notes that amortized data is 'Not supported by get_cost_entries,' and explicitly contrasts its row-truncation behavior with query_unit_costs. It also warns about unsupported secondary_breakdown_by pairs, which prevents misuse.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Tools are organized by resource (budgets, alerts, anomalies, dashboards, cost tags, recommendations), so most are clearly separable. The cost-tag cluster and the dimension/facet listers are the places where an agent could misselect by name, though descriptions resolve the ambiguity.

Naming Consistency5/5

All tools use snake_case verb_noun names with a clear convention: get_ fetches specific items, list_ enumerates collections, and query_ runs time-bucketed or analytical queries. The pattern holds across all 29 tools with no camelCase or mixed verb styles.

Tool Count2/5

29 tools is well past the typical 3–15 sweet spot and even past the 16–25 heavy band, so the surface feels sprawling despite having few duplicates. Each tool maps to a distinct endpoint, but the sheer number makes it a heavy set for an agent to select from.

Completeness2/5

The read-side is strong: costs, usage, tags, budgets, alerts, anomalies, dashboards, recommendations, and data health are all queryable. However, the surface is almost entirely read-only, and descriptions reference absent tools like create_budget, create_alert_subscription, create_dashboard, set_dashboard_widgets, and delete_dashboard, creating dead ends. That is a significant gap for a cost-management platform.

Resources