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

With no annotations, the description carries the full burden, and it does disclose the two most decision-relevant facts: a per-citation price of $0.01 USDC on Solana and a 25-citation cap. It also says what the payment buys (one signed set report) and the grading standard. It does not disclose payment mechanics (prepay vs settle, refunds on failure), idempotency, or error behavior for malformed citation objects, which matters for a paid mutation.

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?

It is one dense sentence, front-loaded with the price and cap before the deliverable, which is the right order for a paid tool. The parenthetical cost formula is efficient rather than redundant. Minor clutter from the version string and duplicated 'per citation in the set' phrasing keeps it from a 5.

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 paid batch tool with no annotations, no output schema, and an opaque parameter, the description does reasonably well by naming the cost, the cap, and the content of the returned report. It is still incomplete on prerequisites (precheck ordering), per-item input requirements, and payment/failure semantics, which an agent needs before spending money.

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?

The schema documents zero percent of the single 'references' parameter and only declares it as an untyped array of objects. The description partially compensates by revealing that each entry is a citation with claimed fields that will be compared against a register record, which is real semantic value. It still leaves the item shape, required per-item fields, and maximum array size undocumented.

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 action on a specific resource: submitting a set of citations and receiving one signed set report with a per-citation outcome (register resolution plus claimed-field match) graded under reference-resolution-set/v1. That is far more precise than the name alone. It stops short of a 5 because it never names its closest siblings (refcheck_check for single citations, refcheck_setprecheck), so the agent must infer the set-vs-single split from the phrase 'in the set'.

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 no explicit when-to-use guidance and no exclusions. The agent is not told whether refcheck_setprecheck must run first, whether this replaces or complements refcheck_check, or when a set submission is preferable to N single checks. The cap of 25 hints at a batch scenario but gives no instruction.

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