get_usageRetrieve spending and GPU-hours for the last N days, broken down by GPU, app, day, and project to track compute costs.
Spending and GPU-hours over the last N days, by GPU, app, day and project.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | The last N days |
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | ||
| daily | Yes | ||
| by_app | Yes | ||
| by_gpu | Yes | ||
| projects | Yes | ||
| sessions | Yes | ||
| gpu_hours | Yes | ||
| spend_usd | Yes | ||
| topups_usd | Yes | ||
| balance_usd | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the disclosure that results are pre-aggregated across four dimensions. It says nothing about whether today is included in the window, timezone, currency of spending, or latency over long ranges.
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?
One tightly packed sentence with the metrics and window front-loaded and no filler. It is slightly telegraphic — the missing verb means the agent reads it as a phrase rather than a statement of behavior.
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?
An output schema exists, so return-shape details are unnecessary, and annotations carry the safety semantics. With only one parameter and one aggregation window, the description covers what the tool produces; only the default-window behavior and inclusion of the current day are left unstated.
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% and the single parameter is fully documented with default 30, minimum 1 and maximum 365. The description's phrase 'over the last N days' merely restates the schema, so the baseline 3 applies.
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?
The description names the two concrete metrics returned (spending and GPU-hours) plus the time window and the aggregation grains (GPU, app, day, project), which is far more specific than the tautological title. It implicitly distinguishes itself from the list_* siblings because it produces an aggregated cost report rather than an inventory, though it never explicitly says so.
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?
There is no statement of when to call this versus list_receipts, list_gpus, or list_projects, and no note on prerequisites or typical queries. The agent must infer the use case from the metric names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.