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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description's only addition is that results carry status and amount and default to newest-first — the latter is already declared as the schema default for `sort`. It says nothing about pagination behavior, result caps (limit max 100), or whether all refunds are returned regardless of status/date filters.

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 short sentence with no padding, but the brevity comes at the cost of clarity — the ambiguous "Label" opener front-loads the least informative word. It is efficiently sized but not well structured for an agent to act on.

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?

A 7-parameter, filterable list tool with no output schema and 57% schema coverage needs the description to explain filtering, paging, and result shape. The single sentence covers none of these, leaving an agent to guess how `status`, `search`, and the date range combine.

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 57%, with `sort`, `limit`, and `offset` undocumented in the schema. The description touches only sort order ("newest request first") and does not explain `search`, `status`, or the `from_date`/`to_date` inclusion semantics beyond what the schema already states. It fails to compensate for the coverage gap on the paging and sort parameters.

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?

"Label refunds with their status and amount" gestures at a listing of refunds with status/amount fields, and "newest request first" implies an ordering. But the verb "Label" is ambiguous (annotate? tag? display?) for a tool named list_refunds, so the reader must infer the actual action. The resource is identifiable, but the verb is not stated cleanly enough to distinguish it from refund_label, refund_batch, or list_transactions.

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 statement of when to use this versus alternatives. Siblings like refund_label, refund_batch, list_transactions, list_receipts, and list_carrier_adjustments are all plausible confusions, and none are addressed. The only usage hint is the default sort order, which is not guidance.

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