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

Annotations already declare the read-only, non-destructive, closed-world profile, and the description goes well beyond them: it defines the statistic D, the permutation null, the k·(1+2n) search cost, the NNI search starting point (each alignment's neighbour-joining tree), and explicitly warns that rate heterogeneity confounds recombination signals (Darlu & Lecointre 2002). That is exactly the interpretive context an agent needs and cannot get from the annotations.

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 dense paragraph, front-loaded with purpose, then data model, statistic, test design, caveat, cost, and file-grouping rule. Nearly every sentence carries distinct information, though the runtime anecdotes (23 s / 48 s / 122 s on Neisseria MLST) are somewhat verbose for the point they make.

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?

With an output schema present, return values need not be described, and the 100% schema coverage plus read-only annotations leave only interpretation and cost to cover — both are handled thoroughly, including input shape, statistical caveats, and scaling limits. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: it explains the `loci` data model (one aligned FASTA per locus, shared taxa names, wired records grouped by the part of the name before ' · ') and ties the cost to `permutations` and locus count, deepening how those parameters drive both semantics and runtime.

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?

Names a specific verb and resource — testing whether loci of a multi-locus alignment have incongruent histories — and pins the exact method (incongruence length difference / Farris et al. 1994). The clause 'a call is a candidate for a tree comparison, never a recombination call' explicitly separates its output from the recombination/mutation framing of the sibling tool `recombine`, so an agent can place it precisely.

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?

Gives clear situational context: it explains the two test scopes (one global, one per-locus against all others with FDR control) and the cost profile (default 99 permutations, search count formula, concrete runtime scaling with taxa), which tells an agent when the tool is affordable. It stops short of naming alternatives such as `compare_trees` or `discover_gene_tree_discordance`, so there is no explicit when-not-to-use routing.

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