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

Annotations mark this readOnly=false and idempotent=false, and the description supplies exactly the context the annotations cannot: every output row is verified gap-stripped against the input, out_path is never overwritten and its directory must pre-exist, and fasta returns None with written_to holding the absolute path. That is substantive behavioral disclosure for a write-capable tool.

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?

Front-loaded with the one-sentence purpose and return contract before the Args block, and every sentence carries information. Slightly dense in the out_path sentence, where a clause about which tools accept written_to as fasta_path could be tightened, but there is no filler.

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?

A 4-parameter mutation tool with an output schema, and the description still tells the agent everything needed: input constraints, sequence-type handling, the return-shape switch on out_path, and how downstream tools consume either form. Nothing an agent needs in order to call it 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 description coverage is 0%, so the description must carry all four parameters – and it does: fasta (2-200 unaligned sequences, gaps refused), sequence_type (dna/protein, declared never sniffed, passed to MAFFT explicitly), fasta_path (file alternative to fasta), and out_path (new file, directory must exist, changes return shape). This far exceeds the schema's bare titles and defaults.

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?

States a specific verb and resource (align unaligned sequences with MAFFT) plus the downstream purpose (ready for infer_tree). It names the exact siblings that consume the output (infer_tree, select_substitution_model, map_positions), so an agent can place it in the workflow without opening other schemas.

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?

Explicitly says input must be UNALIGNED and that gap characters are refused because already-aligned input 'does not need this tool' – a clear when-not condition. It also directs the agent to prefer out_path rather than shuffling rows between calls, which is prescriptive routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description adds useful context about the version fields and the behavior of include_models. It also mentions enforced bounds, which goes beyond the structured annotations without contradicting them.

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 short, front-loaded with the tool's purpose, and each line serves a clear function. The 'Args:' header is slightly redundant with the schema, but there is no wasted prose.

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?

Given the tool's simplicity, the existing output schema, and the annotations, the description is complete enough for correct invocation. It covers the version fields and the one behavioral toggle without needing to restate return formats.

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 0%, so the description must compensate for the single parameter. The line about include_models adds real meaning by clarifying that it controls whether the full substitution-model list is included and warns that the output is long.

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 clearly conveys that the tool reports what the server can do and the limits it enforces, which distinguishes it from the phylogenetic analysis siblings. It lacks an explicit operative verb like 'returns' or 'lists', but the intent is unambiguous.

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?

The description implies this is an introspection capability for discovering server capabilities and limits, but it never explicitly says when to call it versus alternatives. It offers no direct 'use this when' guidance or comparison to sibling tools.

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

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

Annotations already cover read-only, idempotent and closed-world behavior, and the description adds useful substance: the metric used, that equivalent topologies have many valid Newick strings, and that clade differences are part of the result. However, with all three parameters optional and defaulting to null, it never says what happens if neither the two strings nor a path are supplied, nor how malformed Newick is 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 key semantic point — splits, not strings — is front-loaded before the argument list. The Args block is compact and each entry adds information rather than restating the parameter name.

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?

An output schema exists, so return values need no explanation, and the mutually exclusive input modes are spelled out. The remaining gap is the all-optional parameter set: an agent cannot tell from the description what constitutes a valid call (pair of strings vs path) or what happens when everything is null.

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 has to carry all parameter meaning, and it does name and explain all three. 'trees_path' gets the strongest treatment, specifying that the file must hold exactly two Newick trees, A then B, which is meaning nothing in the schema conveys. The two Newick string args are defined only as 'First/Second tree', leaving the pairing A-to-B implied rather than stated.

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?

States a specific metric (Robinson-Foulds distance) applied to a specific resource (two trees), plus the secondary output (which clades differ). The clarification that it compares SPLITS rather than strings sharpens the purpose beyond the title and clearly separates it from the alignment/model siblings.

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?

Explicitly warns that string equality 'answers a different question', which is a genuine when-to-use signal, and frames the two input modes as mutually exclusive ('Instead of the two strings...'). It stops short of naming any sibling tool or stating when a different comparison approach would be preferred.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the mandatory bootstrap policy, cost scaling for replicates, support thresholds for each method, seed caveats, and the risk of silently fitting a nucleotide model to protein data. These are substantive behavioral details not available in 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?

The description is long but appropriately sized for a seven-parameter tool with no schema descriptions. The core purpose and mandatory-bootstrap behavior are front-loaded, followed by a tightly structured parameter list where each entry carries useful context.

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?

Given the high complexity, zero schema description coverage, and the presence of an output schema, the description covers everything needed to call the tool correctly: prerequisites, parameter meanings, cost tradeoffs, and model/sequence-type constraints.

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 0%, so the description must compensate fully, and it does: all seven parameters are explained with formats, defaults, valid ranges, method-dependent replicate costs, and operational caveats. It also clarifies sequence_type is declared rather than inferred and that protein data requires a protein model.

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: build a maximum-likelihood tree and measure bootstrap support. It distinguishes the tool from alignment, model selection, and tree comparison by naming their roles as prerequisites or alternatives.

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 explicitly routes the agent: run align_sequences first if sequences are not aligned, run select_substitution_model first when no model is preferred, and use ufboot when nonparametric bootstrap cost is too high. It also explains that bootstrap cannot be skipped.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so safety is covered; the description adds genuinely new behavioral facts beyond them — 1-based residue counting, gaps excluded from position counts, null positions at gapped rows with `between` supplying flanking residues, and the hidden MAFFT alignment step for unaligned input. It stops short of warning about the cost/nondeterminism of that implicit alignment or what happens on invalid positions.

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 core behavior and the clarifying question are front-loaded, and the args block is compact with one line per parameter. The `aligned` entry carries slightly more prose than the rest, but no sentence is filler.

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?

An output schema exists, so return values need not be fully spelled out, and all seven parameters plus the aligned/unaligned branch are covered. Remaining gaps are edge-case handling: what happens if both or neither of `position`/`column` are supplied, and how `sequence` is matched against `fasta`.

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?

With schema description coverage at 0%, the description must carry all seven parameters, and it does — each of aligned, sequence, position, column, fasta, fasta_path, and sequence_type gets a one-line explanation including the dna default. The weak spot is `sequence`, described only as "the sequence whose residue `position` is meant," leaving unclear whether it is an identifier/name key into `fasta` or the sequence text itself.

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 opening line states a precise verb and two-directional resource: residue -> alignment column, and column -> every sequence. The concrete question it answers ("which residue of B is in the same column as residue N of A") removes any ambiguity about what output to expect, and it is clearly distinct from alignment-building siblings like align_sequences.

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?

The description states both invocation modes explicitly ("Give this or `column`") and explains the branch on `aligned`: true means the input is already an alignment, false means it is aligned with MAFFT first. It does not, however, name a case where an agent should skip this tool entirely or point to a specific better alternative beyond the parenthetical reference to `align_sequences`.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the description is not carrying the safety burden. It adds substantial domain behavior: nucleotide and protein model sets are not comparable, BIC penalizes parameters more heavily, bare 'F81'/'HKY' have equal base frequencies in IQ-TREE, and aliases like JC69/K80/HKY85 are accepted. This is meaningful context beyond the structured fields.

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 front-loaded with the core purpose, then explains why the ranking matters, then lists arguments cleanly. It is appropriately sized for a seven-parameter tool, though the middle rationale sentence is slightly editorial rather than strictly operational.

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?

Given seven parameters, no schema descriptions, and an output schema already present, the description is nearly complete: it covers every parameter and the main semantic caveats around model comparability and naming. It does not address edge cases such as what happens when neither fasta nor fasta_path is supplied, which keeps it from a 5.

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 0%, so the description must carry parameter meaning entirely, and it does. It documents all seven parameters, including criterion choices and their trade-off, seed's role in fixing the engine search, sequence_type's default and model-set implications, and detailed IQ-TREE naming/alias rules for models.

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 opening sentence states a specific verb and resource: 'Compare substitution models and report how much the winner won by.' It also explains the ranking/delta/agreement output, making the tool's role concrete. It does not explicitly distinguish itself from siblings such as infer_tree, so it stops short of a 5.

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?

The description implies when to use it by contrasting a single model name with a full ranking ('A single model name reads as a finding...'), so the usage context is inferable. However, it gives no explicit when-not-to-use guidance and never names an alternative tool, leaving routing to inference.

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

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

Annotations already declare read-only and idempotent behavior. The description adds useful context beyond that: the output has a known true tree, the seed fixes the simulation, protein models produce sequences whose moltype is recorded, and every newick edge needs a branch length. There is no contradiction with 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?

The description is front-loaded with the core purpose, then gives the practical workflow context, then compactly documents each parameter. There is no filler or repetition of schema defaults; every sentence contributes.

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 simulation tool with an output schema and safety annotations already provided, the description covers the essential usage loop, parameter semantics, and expected result semantics. Nothing an agent needs to call it correctly or interpret its output 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 description coverage is 0%, so the description carries the full burden, and it succeeds. It explains newick (true tree with branch lengths), model (substitution model and moltype implication), length (number of sites), and seed (fixes simulation) in plain terms that add meaning beyond the raw schema.

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: 'Generate sequences along a tree you specify, so the true answer is known.' It also orients the tool as the 'positive control for everything else here,' distinguishing it clearly from inference and comparison siblings like infer_tree and compare_trees.

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?

The description gives clear context for when to use the tool: as a positive control for validating inference workflows. It names the follow-up steps (infer_tree, compare_trees) and explains how to interpret failure, but it does not explicitly state when not to use it or name an alternative simulation approach.

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