list_usages

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

readOnlyHint=true already discloses the safety profile, and the description adds useful context about daily granularity and the returned metrics. However, it does not explain behavioral details that matter for a 9-parameter list call, such as pagination defaults, the semantics of the latest flag, or how results are grouped; since the annotation covers the read-only nature, the bar is met at an adequate level without contradiction.

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 two sentences and 18 words, front-loading the action ('List Sub-Account level usage data') before the return-content detail. Every sentence earns its place with no filler or repetition of the tool name.

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?

The tool has 9 optional parameters and no output schema, so the description carries the burden of conveying response shape; it partially does by listing daily metrics but not the overall structure, units, or grouping. It also omits any guidance for distinguishing from list_control_account_usages given the same domain. Adequate for basic invocation but with clear gaps around response format and sibling selection.

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 description coverage is 100%, so the baseline is 3 – every parameter (to, from, page, size, latest, subAccountId, controlAccountId, governanceAccountId, wasabiAccountNumber) is already documented in the schema. The description adds no parameter-specific meaning beyond the schema; the mention of 'daily metrics' aligns with the date range parameters but does not elevate understanding of any single parameter.

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 states a specific verb and resource: 'List Sub-Account level usage data', and the second sentence adds the returned metric types (storage, egress, ingress, API calls). The 'Sub-Account level' qualifier helps distinguish it from sibling list_control_account_usages, though no sibling is named explicitly and 'per Sub-Account' leaves grouping semantics slightly ambiguous.

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?

No guidance is given on when to use this tool versus closely related siblings such as list_control_account_usages, get_control_account_usage, or get_usage. The description never states exclusions, prerequisites, or selection conditions; the only signal is the 'Sub-Account level' phrase, which requires the agent to infer the routing.

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