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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description still adds real behavior: it names the output shape (every row, counts, TSV under the paper's headers) and discloses validation semantics ('an answer missing that is named'). It does not state that nothing is persisted, which would have closed the loop for a mutation-looking input.

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?

Purpose and scope are front-loaded, and each sentence carries information (sections, answer format, return shape, id-enumeration mode, dPCR redirect). The prose is dense and semicolon-heavy with one awkward fragment ('an answer missing that is named'), which costs it the top mark.

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 nested-object, 3-param tool with an output schema, the description supplies purpose, answer schema semantics, usage mode and output form, so an agent can invoke it correctly. It deliberately (and acceptably) duplicates some return detail the output schema already covers rather than omitting anything essential.

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 100% and the answers/_files/_subject params are all richly documented in the schema itself, so the baseline is 3. The description reinforces the answer model (Provided yes/no plus Description/Justification) and the missing-answer rule, but adds little beyond the schema and says nothing about _files/_subject semantics.

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 identifies a specific artifact (the MIQE 2.0 checklist, Bustin et al. 2025, Table 1) and states its scope: every item across five named sections, filled in with the user's answers. It is clear what the tool produces without opening the schema, though the 'action' is expressed as a noun-phrase checklist rather than a crisp verb+resource.

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 an explicit operating mode ('Run with no answers to read the item ids') and routes dPCR users away to dMIQE 2020, which is genuine when-to-use / when-not guidance. It does not address sequencing/submission siblings (e.g. build_ena_submission) that might also be in play, so it stops short of a 5.

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