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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavior beyond that: pending/ambiguous/batched-attribution legs are excluded from settled totals, no signing or execution authority is conferred, and a checksum is explicitly not authenticity or independent settlement proof. Those trust-boundary and aggregation-semantics disclosures are genuinely useful and not obtainable from structured fields.

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 purpose is front-loaded, but the body is a telegraphic run-on of noun fragments and stacked negations that is hard to parse, and "days1–31, default7" is written without spacing. The exclusion list earns part of its place, but a shorter, structured form would convey the same scope and caveats with less decoding effort.

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?

For a single-parameter read-only tool with no output schema, the description covers the data domain, the aggregation rule, the privacy/authority boundaries, and the export path. What is missing is a concrete sense of the returned record shape, but the ledger/voucher framing gives enough for correct invocation.

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?

There is a single parameter with 100% schema description coverage, so the schema already fully documents the 1-31 range and the default of 7. The description's "days1–31, default7" merely restates the schema, adding no new meaning. Baseline 3 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 names a specific verb ("Inspect") and a specific resource ("partial selected-network public web-dispatch transfer ledger and balanced exact micro-USDC vouchers"). The emphasis on "public" and the explicit exclusion of "private invoices" and "customer questions/identities" implicitly separates it from siblings like history_private_jobs_detail and history_private_jobs_export, though no sibling is named. The dense domain jargon keeps it from a 5.

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?

Scope constraints are implied rather than stated as usage rules: "partial selected-network" and "Browser funding and Keryx sponsorship are separate" tell the agent what the data covers, but there is no explicit "use this when / not when" or pointer to history_export, run_owner_export, or history_private_jobs_export as alternatives. The agent must infer the routing from the exclusions list.

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