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

TDQS

A4.5/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint and idempotentHint, the description adds substantial behavioral context: null unit_cost means missing data rather than zero, series truncation at coverage.complete_through is normal, lagging sources lower unit costs, and an empty rows with numerator_status.available=false means a broken metric, not zero spend. These caveats go well beyond the annotations and materially prevent misinterpretation.

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, high-stakes misinterpretation risk: null semantics, missing newest data, lagging sources, broken definitions, allocation policy, and per-customer caveats. It is front-loaded with the core purpose and the most critical null warning immediately after.

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 there is no output schema, the description carries the full burden of explaining the response—and it does: return fields, null meaning, coverage block, numerator_status, per-customer row structure, and currency conventions. It also links to list_unit_metrics for ID resolution and list_cost_tags for allocation policy. Nothing essential for correct invocation and interpretation 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?

The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description does not add much parameter-level detail, though it enriches the meaning of the result (unit_cost, denominator_label, coverage) and references list_unit_metrics for unit_metric_id. It relies on the schema for parameter syntax, which is acceptable given full coverage.

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 opening sentence states a precise verb ('Compute'), a specific resource ('one of this account's saved unit-economics metrics'), and a distinguishing formula ('cost divided by business units'). It also names list_unit_metrics as the source of metric IDs, which separates it from siblings like query_costs or 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?

The description clearly establishes when the tool is appropriate: for saved unit-economics metrics over a date range, and it points to list_unit_metrics for valid IDs. It also warns about differences from raw dimension totals and amortized cost, which implies alternatives without explicitly saying 'use query_costs for raw spend.' This is clear context but lacks a direct when-not-to-use statement.

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