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

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, "tag" to break down by a virtual cost-allocation tag_key (see list_cost_tags) — requires tag_key — or "category" to fold sources into their category (cloud, ai, saas, …), one series per category; "category" cannot be combined with secondary_breakdown_by.
filter_modelNoRestrict to these model values
exclude_modelNoLeave out these model values
filter_regionNoRestrict to these region values
exclude_regionNoLeave out 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)
exclude_clusterNoLeave out these cluster values
exclude_serviceNoLeave out these service values
filter_categoryNoRestrict to sources in these categories (cloud, ai, kubernetes, data, observability, developer-tools, finance, communications, saas, custom)
filter_identityNoRestrict to these identity values
filter_workloadNoRestrict to these workload values
exclude_categoryNoLeave out sources in these categories
exclude_identityNoLeave out these identity values
exclude_workloadNoLeave out these workload values
filter_namespaceNoRestrict to these namespace values
filter_operationNoRestrict to these operation values
exclude_namespaceNoLeave out these namespace values
exclude_operationNoLeave out these operation values
filter_usage_typeNoRestrict to these usage_type values
exclude_usage_typeNoLeave out these usage_type values
filter_resource_idNoRestrict to these resource_id values
exclude_resource_idNoLeave out these resource_id values
filter_linked_accountNoRestrict to these linked_account values
exclude_linked_accountNoLeave out these linked_account values
secondary_breakdown_byNoA second dimension to break spend down by simultaneously with breakdown_by. The allowed pairs depend on the account's sources: a pair that no stored grain covers is rejected unless every source in scope writes the finer detail grain (currently AWS), in which case any pair of service/region/linked_account/usage_type/operation works. Not applicable when breakdown_by is "tag".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedInput schema / properties / breakdown_by / description
      Previous value: -"Dimension to break spend down by, or \"tag\" to break down by a virtual cost-allocation tag_key (see list_cost_tags) — requires tag_key."New value: +"Dimension to break spend down by, \"tag\" to break down by a virtual cost-allocation tag_key (see list_cost_tags) — requires tag_key — or \"category\" to fold sources into their category (cloud, ai, saas, …), one series per category; \"category\" cannot be combined with secondary_breakdown_by."
    • changedInput schema / properties / breakdown_by / enum
      Previous value: -[
      -  "service",
      -  "region",
      -  "linked_account",
      -  "usage_type",
      -  "operation",
      -  "identity",
      -  "namespace",
      -  "workload",
      -  "cluster",
      -  "resource_id",
      -  "model",
      -  "tag"
      -]New value: +[
      +  "service",
      +  "region",
      +  "linked_account",
      +  "usage_type",
      +  "operation",
      +  "identity",
      +  "namespace",
      +  "workload",
      +  "cluster",
      +  "resource_id",
      +  "model",
      +  "tag",
      +  "category"
      +]
    • addedInput schema / properties / exclude_category
      Added value: +{
      +  "description": "Leave out sources in these categories",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_cluster
      Added value: +{
      +  "description": "Leave out these cluster values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_identity
      Added value: +{
      +  "description": "Leave out these identity values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_linked_account
      Added value: +{
      +  "description": "Leave out these linked_account values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_model
      Added value: +{
      +  "description": "Leave out these model values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_namespace
      Added value: +{
      +  "description": "Leave out these namespace values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_operation
      Added value: +{
      +  "description": "Leave out these operation values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_region
      Added value: +{
      +  "description": "Leave out these region values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_resource_id
      Added value: +{
      +  "description": "Leave out these resource_id values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_service
      Added value: +{
      +  "description": "Leave out these service values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_usage_type
      Added value: +{
      +  "description": "Leave out these usage_type values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / exclude_workload
      Added value: +{
      +  "description": "Leave out these workload values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / filter_category
      Added value: +{
      +  "description": "Restrict to sources in these categories (cloud, ai, kubernetes, data, observability, developer-tools, finance, communications, saas, custom)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed3 schema fields changed
    • changedInput schema / properties / breakdown_by / enum
      Previous value: -[
      -  "service",
      -  "region",
      -  "linked_account",
      -  "usage_type",
      -  "operation",
      -  "identity",
      -  "namespace",
      -  "workload",
      -  "cluster",
      -  "resource_id",
      -  "tag"
      -]New value: +[
      +  "service",
      +  "region",
      +  "linked_account",
      +  "usage_type",
      +  "operation",
      +  "identity",
      +  "namespace",
      +  "workload",
      +  "cluster",
      +  "resource_id",
      +  "model",
      +  "tag"
      +]
    • addedInput schema / properties / filter_model
      Added value: +{
      +  "description": "Restrict to these model values",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / secondary_breakdown_by / enum
      Previous value: -[
      -  "service",
      -  "region",
      -  "linked_account",
      -  "usage_type",
      -  "operation",
      -  "identity",
      -  "namespace",
      -  "workload",
      -  "cluster",
      -  "resource_id"
      -]New value: +[
      +  "service",
      +  "region",
      +  "linked_account",
      +  "usage_type",
      +  "operation",
      +  "identity",
      +  "namespace",
      +  "workload",
      +  "cluster",
      +  "resource_id",
      +  "model"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / secondary_breakdown_by / description
      Previous value: -"A 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\"."New value: +"A second dimension to break spend down by simultaneously with breakdown_by. The allowed pairs depend on the account's sources: a pair that no stored grain covers is rejected unless every source in scope writes the finer detail grain (currently AWS), in which case any pair of service/region/linked_account/usage_type/operation works. Not applicable when breakdown_by is \"tag\"."
  4. First observed

TDQS

A4/5.0
Behavior5/5

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

Far exceeds annotations: it discloses cost_basis estimation semantics and the duty to qualify estimates, currency conversion basis, cost_per_unit scale pitfalls, coverage.complete_through latency, and lagging_sources under-counting. This is exactly the behavioral context an agent needs for a read-only analytics tool.

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?

The core purpose is front-loaded, but the description runs several dense paragraphs that mix invocation guidance with output-field semantics, including lengthy asides (token vs 1k-token quoting, cost_basis). Some of this could be tightened even given the 32-param complexity.

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?

No output schema exists, so the description carries the return-value burden and does so thoroughly (currency, cost_basis, quantity/unit/cost_per_unit, coverage fields). For a broad analytics query tool, an agent has enough to interpret results and caveats 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?

With 100% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: it explains that 'identity' is per-actor spend not always populated, and that 'category' folds sources into series and cannot combine with secondary_breakdown_by. Other params are left to the schema.

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

Purpose4/5

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

The opening sentence states a specific verb (Query) and resource (time-bucketed spend), lists the breakdown dimensions, and notes the tag path via list_cost_tags. It distinguishes from query_unit_costs behaviorally, though it does not fully contrast with get_cost_entries or query_usage siblings.

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?

Usage context is implied ('Mirrors the GET /api/analytics endpoint') and one sibling (list_cost_tags) is referenced for tags, plus a contrast with query_unit_costs. But there is no explicit when-to-use-this-vs-get_cost_entries/query_usage guidance, so selection still requires inference.

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