Skip to main content
Glama

aiworkhub_task_cost_ledger

Read-only

READ-ONLY: bounded cost summary, with opt-in detailed dimensions.

Instructions

READ-ONLY: bounded cost summary, with opt-in detailed dimensions.

Default mode retains cost/cache truth plus provider, model and day aggregates, and stays bounded as usage history grows. by_model, cost_per_accepted_outcome.routes and model_outcomes.models each return at most _COST_LEDGER_SUMMARY_TOP_N rows. by_day is bounded as two independent groups -- up to _COST_LEDGER_SUMMARY_TOP_N most-recent dated buckets beside up to _COST_LEDGER_SUMMARY_TOP_N undated ones -- so its exact ceiling is 2 * _COST_LEDGER_SUMMARY_TOP_N rows, not N; undated spend is retained rather than made to compete with real days for one shared bound. Every bounded dimension carries explicit total_count/ returned_count/truncated/ranked_by metadata under summary_row_bounds, so no row is dropped silently. The two model-keyed dimensions rank by observed dollars rather than tokens; a bucket whose provider reported no price ranks on its activity instead of being cut as though it were free, and a partially priced bucket ranks in both orders so one cheap priced record cannot hide the magnitude whose dollars are still unknown. Per-runner and per-topic maps are available with full=true; task rows remain independently opt-in through include_tasks.

Kept rows are also narrower than full=true. Each kept model's cost_per_accepted_outcome.routes adapter folds its family/risk partitions into one total row, re-derived from summed counters so an UNKNOWN partition keeps it UNKNOWN; the fold is receipted under summary_row_bounds. by_day rows keep records, total_tokens, cost_usd, cost_unknown_records and cache_hit_ratio. full=true returns both exactly as built.

The repository binding is what makes those aggregates answerable. build_cost_ledger reads canonical usage events only when it is given a root; without one it parses the human-readable usage report, whose lines carry no model, provider or timestamp, so every dimension this docstring promises collapsed to unknown. Measured 2026-09-02 on this repository: unbound 590 rows / 1 model / 1 provider / 1 day / 0 usage-observed / 0 cache-observed / 0 routes; bound 3,509 rows / 28 models / 8 providers / 36 days / 2,267 usage-observed / 1,869 cache-observed / 13 routes. Every other caller (dashboard, manager tools, evidence instruments) already passed a root; this tool -- the manager's own cost surface -- did not, so routing by cost and difficulty had no measurement to steer by (NF-2026-00542).

Input Schema

NameRequiredDescriptionDefault
fullNo
topicNo
runnerNo
statusNo
include_tasksNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description discloses substantial behavior: row bounds, exact ceiling behavior for by_day, truncation metadata under summary_row_bounds, ranking by observed dollars, handling of unpriced and partially priced buckets, and folded route rows. It also explains the repository binding requirement and its effect on whether dimensions resolve to real values. This is unusually rich behavioral context and does not contradict the annotations.

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

Conciseness2/5

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

The first sentence is front-loaded and useful, but the rest is heavily overloaded with internal constants, implementation rationale, a dated measurement narrative, and a bug reference. Much of this reads like a changelog or docstring, not concise agent-facing guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema and read-only annotation reduces what the description must explain about return shape and safety. Still, for a five-parameter cost-ledger tool with zero schema description coverage, the missing topic/runner/status semantics and the noisy bug-history narrative leave the definition only partially complete for reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It adds some meaning for full and include_tasks, but topic, runner, and status are not defined at all, leaving three of five parameters undocumented in both schema and prose.

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 identifies a specific operation and resource: a read-only, bounded cost summary with opt-in detail. The body clarifies aggregates by provider, model, day, runner, topic and task, so the agent can understand what the tool returns. It does not clearly contrast itself with sibling reporting tools such as aiworkhub_task_usage_report, which keeps it from a 5.

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?

The description explicitly explains default bounded mode, when to use full=true for per-runner/per-topic maps, and when to opt in task rows with include_tasks. However, it gives no guidance on when to choose this tool over sibling reporting tools, nor any exclusions or prerequisites for the topic/runner/status filters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools