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

With no annotations, the description carries the full disclosure burden, and it does so thoroughly: it reveals payment requirements via x402, the unpaid isError path, signing and reproducibility guarantees, no-LLM processing, per-claim source/time metadata, and the returned settlement/transaction/network fields. This goes well beyond a generic 'verify citations' statement.

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 description is dense but every sentence carries high-value operational information: output format, input modes, authenticity guarantees, payment, failure mode, and alternatives. The core purpose is front-loaded and the sibling routing is placed at the end.

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 complex paid tool with no output schema and no annotations, the description covers output contents, payment/settlement fields, error behavior, reference limits, and use-case fit. An agent has enough context to decide whether to call this tool, how to handle unpaid or successful calls, and when to route to a sibling.

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 67%, so the description is not fully excused from explaining inputs. The description meaningfully adds that the input is structured references or BibTeX and states the 50-reference limit. It does not explain the options object beyond what the schema lists, leaving strict_authors and include_unpaywall somewhat underspecified.

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 opens with a specific purpose: "Verify a bibliography," then details the exact verification dimensions (existence, resolution, retraction, metadata match, fabrication risk). It also positions the tool against evidence_pack_preview / evidence_pack by stating it is for checking references the agent already has rather than finding papers.

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?

It gives explicit context for when to use the tool — checking existing references — and names the alternatives for related-but-different tasks: use evidence_pack_preview / evidence_pack when looking for papers for a question or claim. It also clarifies the paid-call flow and unpaid error behavior, leaving little ambiguity about invocation.

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