Get a summary of actual recorded LLM spend: total cost, request count, and breakdowns by model and provider, from usage events previously logged via record_usage. Use when the user asks what they've actually spent, as opposed to a hypothetical cost estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (default: 30, max: 365) | |
| org_id | No | Optional organisation ID filter |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the data source (previously logged usage events via record_usage), implying it returns only recorded spend and not live provider billing, but it says nothing about permissions, empty-state behavior when nothing has been logged, or aggregation semantics for the look-back window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the first states what is returned and its provenance, the second states the usage condition. The purpose is front-loaded before the when-to-use clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by naming the return contents (total cost, request count, model and provider breakdowns). With only two fully documented optional parameters and no mutation involved, this is nearly complete; the only gap is scope behavior for the days window and org filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (days, org_id) fully described including default and max, so the schema already does the heavy lifting. The description adds no syntax or scoping detail beyond mentioning model/provider breakdowns, which are not themselves parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (get a summary of recorded LLM spend) and enumerates the returned dimensions: total cost, request count, and breakdowns by model and provider. It also names the upstream sibling record_usage as the data source, so an agent can tell exactly what population this reads from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule: 'Use when the user asks what they've actually spent, as opposed to a hypothetical cost estimate.' This cleanly separates it from estimate_cost/predict_cost in the sibling list. It stops short of naming the alternative tool or stating exclusions (e.g. session-scoped usage), so it is clear context rather than a full routing table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.