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

With no annotations at all, the description carries the full burden and does substantive work: it discloses that the call is FREE, that it is rate-limited to 100/day per wallet, that 'caller' must be passed to attribute the quota, and that the response contains both an assessability verdict and an exact fee line. It omits what 'assessability' verdicts look like and any error/failure behavior, so it is not fully complete.

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?

A single front-loaded sentence leads with 'FREE set pre-check', then layers quota, scope, and pricing. Every clause carries information (cost, limit, cardinality, price formula), though the nested parentheticals and em-dash make it slightly dense to parse.

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?

There are no annotations, no output schema, and no schema descriptions, so the description must cover everything — and it does cover pricing, quota, cardinality, and the shape of the returned fee line. The remaining gap is material: the opaque `references` item objects and the meaning/categories of 'assessability' are undefined anywhere, so an agent cannot construct a valid call payload from this definition alone.

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 coverage is 0%, so the description must compensate. It does explain `caller` (wallet identity for the 100/day quota) and gives `references` a cardinality of 1-25, which the schema does not. However, the reference objects are typed as bare `object` with no fields, and the description says nothing about their required structure, leaving the most important parameter half-defined.

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 verb and resource: a free pre-check that assesses 'a citation set (1-25 references)' and returns the set's fee line. The word 'set' plus the 1-25 cardinality implicitly distinguishes it from the single-citation refcheck_precheck/refcheck_check siblings, but no sibling is named explicitly, leaving the boundary with refcheck_setcheck unstated.

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?

Usage is implied by 'pre-check' and by the free-quota framing, and the caller requirement is spelled out as a precondition. There is no explicit guidance on when to choose this over refcheck_precheck or refcheck_setcheck, and no stated exclusion or next-step (e.g., which tool to call after a positive pre-check).

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