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

Annotations already establish readOnly/no-destructive/closed-world, so the bar is lower, and the description still adds substantive behavior: judgments are chemistry- and instrument-dependent ('a pool balanced on a NovaSeq 6000 is not balanced on a NovaSeq X'), the distance guarantee is metric-dependent, and the hopping output is explicitly bounded ('multiplies the published RANGE... it never predicts a rate for your run'). It does not discuss runtime cost or how large a pool can be handled.

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 single dense paragraph front-loads the core question before listing the checks, and every clause maps to a real output dimension rather than filler. It is on the long side and the em-dash chains make it slower to scan than it needs to be, but nothing is genuinely redundant.

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 10-parameter tool with nested record references, four enums, and an output schema, the description fully covers what gets evaluated and flags the interpretive limits of the hopping estimate. Since an output schema exists, it needn't explain return values; the remaining gap is guidance on which sibling tool to prefer for narrower questions.

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 enum parameters already carry per-value explanations, so the schema does the heavy lifting. The description adds framing — that instrument chemistry drives color balance and index-2 orientation, and that metric choice changes safety — but this largely restates what the schema's own parameter text says, so the baseline 3 applies.

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 question ('Will this pool of sample indexes actually sequence?') and then enumerates exactly which checks produce the verdict: duplicates, uniform length, guaranteed vs claimed distance, per-cycle color balance, index-2 orientation, and index-hopping exposure. That vocabulary (i7 x i5, index-2 orientation, hopping) distinguishes it clearly from near-neighbors like check_color_balance, audit_barcodes, or assemble_index_oligos.

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 timing is stated implicitly but clearly: it's a pre-load/pre-run check on 'the indexes a lab is about to load', and the kit/pool parameters define the two input paths. What's missing is explicit routing — it never names a sibling (e.g. check_color_balance for a standalone balance question, or audit_barcodes for demultiplexing) or states when not to reach for this tool.

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