Skip to main content
Glama

query_unit_costs

Read-onlyIdempotent

Compute one of this account's saved unit-economics metrics (see list_unit_metrics) over a date range — the cost of a slice of spend divided by the business units it produced. Each row carries cost (the numerator, in the USD base like every other figure this server returns), quantity (the denominator, a raw count with no currency), and unit_cost.

CRITICAL: unit_cost is null whenever it could not be computed, and null does NOT mean zero. It means one half of the fraction is missing for that period — either no usage was ingested (a telemetry gap) or no cost data has landed yet. Do not describe a null unit cost as a cost of zero, and do not average nulls in as zeroes; the coverage block reports how many rows are affected and why. Always read unit_cost together with denominator_label (e.g. "per 1k requests"), which names what it is quoted against — a per-1k figure reported as a per-request figure is wrong by three orders of magnitude.

The series stops at coverage.complete_through rather than at the requested end_date whenever cost data for the newest periods has not arrived yet (it lands hours-to-a-day after the period it covers, while usage telemetry is pushed live). A short series is therefore normal and is NOT evidence that spend or usage stopped — say what it is complete through instead. coverage.lagging_sources, when non-empty, is the opposite case: a cost source that is behind or has stopped reporting, so recent periods are missing its spend and their unit costs read lower than the truth.

If numerator_status.available is false, the cost source this metric measured has been removed from the account and rows is empty. That is a broken definition, not a period of zero spend — never report it as costs having fallen.

Amounts are billed cost, never amortized, regardless of any cost_metric used elsewhere. A tag-scoped metric inherits that tag_key's allocation policy, so its numerator may include a redistributed share of shared spend (see list_cost_tags' redistribute_bucket) and will not match a raw dimension total.

A metric whose denominator_mode is "per_customer" returns one row per (period, customer) and a customers block splitting them into matched, cost_without_usage (spend attributed to a customer who is not sending telemetry) and usage_without_cost (telemetry from a customer whose spend is not being allocated). Those two lists are the honest caveat on any per-customer figure and are worth mentioning when either is non-empty.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO-8601 end of the date range (exclusive)
group_byNoTime bucket size (default: day)
start_dateNoISO-8601 start of the date range (inclusive)
unit_metric_idYesid of a metric returned by list_unit_metrics

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial behavioral context on top: null `unit_cost` is not zero, series truncation at `coverage.complete_through`, `lagging_sources` meaning, empty rows from removed cost sources, billed-not-amortized semantics, and tag redistribution effects. This is exactly the beyond-annotations disclosure the dimension rewards.

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

Conciseness4/5

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

The core operation is front-loaded in the first sentence and each subsequent paragraph addresses a distinct failure mode (nulls, truncation, removed sources, per-customer splits). It is long, but the volume is largely justified by the absence of an output schema; a few caveats 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?

With no output schema and a read-only annotation profile, the description carries the return-value burden itself and does so thoroughly — row fields, `coverage`, `numerator_status`, `customers` block, and `denominator_label`. An agent has everything needed to call and correctly interpret it.

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 coverage is 100% and already documents `start_date`, `end_date`, `group_by`, and `unit_metric_id`, so the baseline is 3. The description adds interpretation context around the date range (coverage stopping early) but nothing about parameter syntax or defaults beyond the schema.

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 — computing a saved unit-economics metric (cost numerator ÷ business-unit denominator) over a date range — and explicitly ties it to `list_unit_metrics` for metric selection, which separates it from `query_costs` and `query_usage`.

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

Usage Guidelines4/5

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

Clear context for use: the metric must come from `list_unit_metrics`, the date range is bucketed by `group_by`, and it explains when results are legitimately short (cost lag) versus broken (`numerator_status.available=false`). It never explicitly names when to prefer `query_costs`/`query_usage` instead, so it stops short of full alternative routing.

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