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

With annotations already flagging destructiveHint=true and openWorldHint=true, the description still adds meaningful context: the 402/x402 pricing terms, free-call allowance, the private issuer-ledger model, the requirement for signed mandates and single-use action grants, and the explicit 'grants no authority and never supplies server credentials' caveat. What it fails to disclose is what the destructive operation actually destroys or what a failed review/version conflict looks like.

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 first sentence front-loads pricing and access terms, then the operating boundary appears, then trailing credential/policy boilerplate. The content is dense but riddled with legalese ('This current money service follows its published inspection, policy evaluation or private invoice contract') that does not help an agent decide or call correctly, so several sentences fail to earn their place.

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 four-mode, 15-parameter, nested-object tool with no output schema and 0% schema description coverage, the description is far from complete: it does not enumerate modes, explain any parameter, describe return values (e.g., the inv_... id and version counter), or clarify version-conflict behavior implied by expected_version being capped at 3.

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% across 15 parameters including a nested run_binding object, so the description carries the full explanatory burden — and it largely does not deliver. It only gestures at categories ('invoice amounts, parties, run references') without explaining amount_atomic units, buyer_wallet format, invoice_id, expected_version semantics, or the five run_binding sub-fields, leaving the agent to infer everything from regex patterns.

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 conveys the general domain — signing issuer-wallet ownership proof, creating an invoice record, attaching run references, and recording a review — and it distinguishes itself from the Invoices product for actual payment collection. However, the four concrete modes (create_invoice_reference, read_invoice, bind_invoice_to_run, review_invoice) are never named, and the purpose is tangled up with pricing and legal boilerplate, so an agent must open the schema to learn what operations exist.

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 one explicit routing statement — 'Payment collection uses the separate Invoices product' — which tells the agent when not to use this tool. The 'Operating boundary' sentence also implies the human-issuer review flow. But no guidance separates this rail from the many sibling rails (decision-packet-rail, work-order-rail, escrow-lite), and there is no indication of which mode to pick for which task.

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