Fetch a live snapshot of current unbilled usage plus historical billed costs, segmented by compute, storage, network, and other. See your total cloud spending at a glance.
Current unbilled usage (a live snapshot) plus historical already-billed cost broken down by Compute/Storage/Network/Other — the same data the dashboard's own Usage Billing page shows.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, which cover the core non-mutating nature. The description adds meaningful behavioral context by describing the data as a 'live snapshot' and distinguishing between unbilled and already-billed historical cost, plus the availability of component-wise breakdown. This provides clarity beyond the annotations without contradicting them.
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?
The description is a single, well-structured sentence that front-loads the core purpose and scope, then adds the relevant breakdown and dashboard reference. No unnecessary words; every clause adds value.
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?
Given the tool has no input parameters, annotations carrying the safety profile, and no output schema, the description provides a useful sense of the response scope (unbilled vs billed, categories) that an agent can act on. It could mention whether the snapshot is real-time or delayed, but the 'live snapshot' mention covers much of that. The description is sufficiently complete for a zero-parameter, read-only tool.
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?
The tool accepts zero parameters, so the description need not explain any. The baseline of 4 for zero parameters applies; the description does not add any parameter-specific detail, which 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?
The description clearly states the verb ('get') and resource ('usage billing'), and specifies the content: current unbilled usage plus historical billed cost, broken down by categories. It also anchors to the dashboard's Usage Billing page, giving a concrete reference. However, it does not explicitly distinguish this tool from the sibling get_usage_billing_line_items, which may offer similar data at a different granularity.
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?
The description implies when to use this tool: it provides a summary breakdown of both unbilled and billed usage, similar to the dashboard page. It does not explicitly state when to prefer this over alternatives like line items or VPS-specific billing, but the summary nature is reasonably implied. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.