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

The description does add one genuinely important behavioral fact: 'Each call also advances the scan', meaning the call mutates server-side progression state. That directly conflicts with idempotentHint=true in the annotations, and sits uneasily with readOnlyHint=true. Beyond that single clause it says nothing about how to detect completion, what happens on a duplicate call, or token expiry.

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 short sentences plus a hosting tag, with the report contents and the state-advancement warning both front-loaded. The opening fragment 'Progress or the finished report' is grammatically awkward and slows parsing, but nothing is padded or redundant.

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?

With no output schema and 0% parameter coverage, the description has to explain the return shape and lifecycle, and it only gestures at it ('by supplier, by day, transactions'). There is no indication of how a caller knows the scan has finished versus is still in progress, which is the central question for a tool whose whole job is progress reporting.

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 0%, so the description carries the full burden, and it only names reportId and reportToken without explaining their format, lifetime, or origin. The third parameter, currency, is never mentioned at all, so an agent has no idea what it controls or what the default output currency is.

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 deliverable (a wallet spend report broken out by supplier, by day, and by transaction) and the two identifying inputs, so the resource is identifiable. But the phrasing 'Progress or the finished report' is not a clean verb+resource statement and it never distinguishes itself from the obvious sibling ledger_wallet_start or ledger_gateway, leaving the agent to infer that this is the polling step of a two-call flow.

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 an implied sequence (this is called with a reportId + reportToken, most likely obtained from ledger_wallet_start), but the description never states when to call it versus ledger_wallet_start, ledger_gateway, or how often to poll. The only explicit guidance is a cost note, '(free)', which is useful but is not when-to-use guidance.

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