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

No annotations are provided, so the description carries the full burden. It discloses useful behavioral context: the taxonomy-label/mapping-file prerequisite and the whitelist/allowed-read-root security constraint on files. It is silent, however, on whether the operation is read-only and on any rate/side-effect behavior (return shape is covered by the output schema).

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 core purpose, followed by the CLI equivalent and an efficient Args block. The figtreekit equivalence line is somewhat expendable, but overall it is tight and well structured with little waste.

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 six params, 0% schema coverage, and an existing output schema, the description covers prerequisites, security constraints, and every parameter, so it is largely self-sufficient. It stops short of an explicit sibling note, which is the only real gap for an agent choosing between this and check_monophyly.

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%, yet the description compensates well by documenting all six parameters, including format hints (Newick/Nexus content, domain..species for rank, CSV/TSV for the mapping file, prefix:rank list, minimum group size). This meaningfully exceeds the raw schema, though a couple of entries remain terse.

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+resource+scope: "Analyze monophyly of all groups at a given taxonomic rank." This is clearly distinguishable in scope from a general clade checker, but it never explicitly names or contrasts with the close sibling check_monophyly or taxonomy_completeness. Clear purpose, missing explicit sibling differentiation.

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?

Provides a meaningful precondition ("Requires terminal labels carrying taxonomy info, or a whitelisted mapping file") which tells the agent when the tool is applicable. However, it names no alternatives and gives no explicit when-to-use vs check_monophyly guidance. Usage is implied via prerequisites rather than stated.

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?

With no annotations, the description carries the full behavioral burden, and it does add real processing context: validation of all accepted parameters before execution and the deterministic execution order (annotations → auto-color/collapse-rank → collapse operations) matching the CLI. It stops short of the higher-value disclosures an agent needs for a tool that exports files — whether it writes/overwrites anything, where output goes, or what happens on validation failure.

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 sibling differentiation are front-loaded, then processing behavior, then a clean Args list — a logical order with no filler. It is somewhat dense with parenthetical asides and the long validation sentence could be tightened, but every sentence carries information.

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 13 parameters, zero required, 0% schema coverage, and no annotations, the description should resolve how to actually invoke the tool meaningfully; it instead documents only a subset of params and never explains valid combinations or required inputs when everything is optional. The presence of an output schema excuses it from describing return values, but the input-side gaps remain.

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, and it does explain several non-obvious params: config ('figtree-block key → value mapping, dot-separated'), operations ('same schema as style_tree'), taxonomy_levels ('prefix:rank,...' active during loading and taxonomy analysis), and seed ('reproducible tree selection for multi_tree="random"'). But roughly half the 13 parameters (tree_file, tree_content, tree_index, run_name, taxonomy_mapping_file, multi_tree) get no explanation in either schema or description, so coverage is only partial.

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 ('apply') and the exact resources it operates on ('a FigTree JSON config (figtree-block keys) plus an ordered operations list') and its output ('export Nexus'). It also explicitly differentiates itself from the sibling style_tree ('Leaner than style_tree for agent-driven advanced tweaks'), so an agent can pick between them without opening either schema.

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 a clear selection signal against one sibling — use this when you want the 'leaner' path for 'agent-driven advanced tweaks' versus style_tree. However it provides no explicit when-not conditions and never addresses overlap with the separate export_nexus or run_figtreekit_cli siblings, even though it also claims to export Nexus, so routing is partly left 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?

No annotations are provided, so the description carries the full behavioral burden. 'Check' and 'return actionable hints' imply a non-mutating diagnostic, but the description never confirms whether it modifies the environment, downloads anything, or requires permissions, and it omits any cost or latency expectations.

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?

Two short lines with the core purpose front-loaded and no filler; the Args block is compact. Slightly terse for the amount of behavioral information an annotation-free tool needs, but nothing is wasted.

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 described, and the single-parameter surface is simple. Still, with no annotations the description should have clarified side effects (does the check only report, or also fix/install) to be complete for an agent deciding whether it is safe to call.

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, and it does: it explains jar_path is optional, is an explicit path, and overrides auto-detection. That is the key semantic the bare 'string' schema lacks, though format expectations (absolute vs relative) are unstated.

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 (check) and concrete resources (Java 8+ and figtree_patched.jar) plus the outcome (actionable hints), which is far more informative than a tautology. It does not, however, distinguish itself from adjacent siblings such as setup_figtree or get_environment, so an agent must infer which diagnostic to call.

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?

There is no when-to-use guidance, no statement of when this is preferable to setup_figtree or get_environment, and no prerequisites. The only routing hint is the optional jar_path override, which is about invocation, not tool selection.

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?

With no annotations, the description must disclose behavior. It usefully states that special identifiers LUCA/LACA/LBCA/root are supported, that tree_file must be inside an allowed read root, and that strict=True raises monophyly_error immediately. However, it omits explicit read-only/safety information and side-effect behavior, leaving some burden unmet.

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 purpose and key behavior, then follows with a compact Args list. It is largely efficient, though the Args section is verbose relative to the schema, which is necessary here because the schema has no descriptions.

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 explained. The description covers all parameters and key behavior like strict error handling and allowed read roots, but it still lacks usage guidance and sibling differentiation, which keeps it from being fully complete.

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 is the sole source of parameter meaning. It documents all five parameters, including Newick/Nexus format for tree_content, allowed read root for tree_file, group formats and special identifiers for groups, a prefix:rank example for taxonomy_levels, and failure semantics for strict.

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 uses a specific verb ('Check') and resource ('monophyletic') for taxonomic groups, clearly stating what the tool does. It does not differentiate from siblings such as validate_tree or analyze_taxonomy, which likely also operate on tree/taxonomy data, so it falls 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 lists capabilities and arguments but provides no when-to-use guidance, prerequisites, or alternatives. It does not explain when an agent should choose this tool over siblings like validate_tree or analyze_taxonomy.

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?

No annotations are provided, so the description carries the burden and does well: it discloses the timing of removal (before the tree is loaded/exported) and a non-obvious edge case (Nexus root markers [&R]/[&U] are preserved so rooting is unchanged). It doesn't cover permissions or what the result looks like, but the side-effect disclosure is genuinely beyond structured data.

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 action and scope are front-loaded in the first sentence, followed by a compact Args block that pairs each documented parameter with its meaning and default. Slightly prose-heavy in the second sentence but no wasted sentences.

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 described, and the description covers scope, side effects, and the annotative semantics of its flags. The only real gap is the unexplained input-source parameters, which prevents this from being fully self-contained.

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. It documents three of six parameters well, including defaults and the subtle strip_annotations behavior, but run_name, tree_file, and tree_content are left completely unexplained, leaving half the surface undocumented in either place.

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 ('Clear') plus a well-defined resource ('highlight and collapse annotations, including embedded ones'), and explicitly carves out what is NOT handled (colors/fonts, routing to color_clade / set_clade_font). An agent can distinguish this from highlight_clade, collapse_clade, and color_clade without opening any schema.

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?

Clear context on when the tool applies: it removes both pending annotations and embedded '[&!hilight=...]'/'[&!collapse=...]' comments before the tree is loaded/exported, and it names sibling alternatives for the excluded color/font concerns. It stops short of explicitly stating when to prefer this over siblings like highlight_clade or collapse_clade as a cleanup step, so not a full 5.

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?

No annotations are provided, so the description carries the full burden. It discloses the visual outcome (triangle+label vs cartoon) but says nothing about whether the underlying tree is mutated, whether tree_file/tree_content is required, permission needs, or reversibility.

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?

Short and front-loaded: the purpose sentence comes first, followed by a compact Args example. No padding, though the example formatting is slightly noisy.

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, but this is a mutation-style tool with no annotations and three undocumented parameters. The critical distinction between tree_file and tree_content (likely mutually exclusive inputs) is never addressed, leaving the agent guessing.

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% and 4 parameters exist. The description richly documents the nested 'collapses' structure (taxa, label, collapse_type values), which is genuinely beyond the bare schema, but run_name, tree_file, and tree_content are left entirely unexplained.

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 (collapse) and resource (clades) with the selection mechanism ('by exact taxon names') and the two output styles ('collapse' triangle+label vs 'cartoon'). This is clear enough to distinguish it from collapse_rank on style grounds, though it never names the siblings collapse_group or collapse_rank.

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 phrase 'by exact taxon names' implies the usage condition relative to group- or rank-based collapsing, but there is no explicit when-to-use, when-not, or named alternative. The agent must infer routing from the phrase alone.

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?

With no annotations present, the description carries the full burden and does add real behavioral context: failed group lookups are recorded as per-group 'skipped' entries and never abort the request, while strict=True converts that into a monophyly_error. It still omits what the collapse actually does to the output tree and whether the operation is reversible.

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 the monophyly caveat are front-loaded in the first sentence, followed by an efficient Args block. The Google-style docstring is reasonably tight, though a little structural overhead is spent on the Args header rather than 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?

An output schema exists, so return values needn't be described, but for a 7-parameter tree-mutation tool with no annotations the description leaves the tree input parameters and its relationship to sibling collapse tools unexplained.

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 must compensate, and it documents four parameters (groups with an example object shape, strict, taxonomy_levels, taxonomy_mapping_file). It leaves run_name, tree_file, and tree_content entirely unexplained, so roughly half the parameters remain undocumented in both places.

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 (collapse clades) and resource (taxonomic group name) with a monophyly pre-check, and notes LUCA/LACA/LBCA/root support. It implicitly separates itself from collapse_clade and collapse_rank by operating on group names rather than clade IDs or ranks, though it never names those siblings directly.

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 is implied by 'by taxonomic group name' versus the rank/clade siblings, and the strict semantics give some context for when a failure should abort. However, there is no explicit statement of when to choose this tool over collapse_clade or collapse_rank, nor any stated prerequisites for the tree input.

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?

No annotations are provided, so the description carries full behavioral burden. It does disclose one real behavior — strict causes failure when a monophyletic group cannot be collapsed — but says nothing about what collapsing does to the tree, whether inputs are mutated or written to new files, or permission/whitelist constraints beyond the vague '(whitelisted)' note.

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 lead sentence is front-loaded and states purpose plus the CLI equivalence in one line, followed by a compact Args list. Every line carries information; the only cost is the docstring indentation that makes it slightly less scannable as tool 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?

An output schema exists, so return values need not be described, but the input story is incomplete: four parameters, notably the tree source (tree_file/tree_content) and run_name, are undocumented anywhere, and there is no guidance on how tree_file and tree_content interact or which is preferred.

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% across 9 parameters, so the description must compensate. It documents 5 of them (rank, collapse_style, auto_color_rank, strict, taxonomy_mapping_file) and usefully enumerates collapse_style values that the schema lacks enums for, but leaves run_name, tree_file, tree_content, and taxonomy_levels — including the core tree-input parameters — completely unexplained.

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 concrete verb+resource+scope: collapse monophyletic groups at a given taxonomic rank, with the optional pre-coloring step called out. The 'at a rank' framing partially distinguishes it from sibling collapse_clade/collapse_group, though it never names those siblings to make the boundary explicit.

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?

There is no statement of when to use this over collapse_clade, collapse_group, or run_figtreekit_cli, and no prerequisites for tree input. The only contextual hint is that taxonomy_mapping_file is for trees whose taxonomy is not embedded in tip labels, which is a narrow edge case rather than general 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a tree mutation but does not state what is modified, whether it needs an existing run/session, or what happens to prior colorings. Only the all-flag semantics are disclosed.

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 core action and its branching behavior, followed by a compact example. Every sentence earns its place, though the Args example is terse and slightly cryptic for the colors structure.

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 explained, but for a 4-parameter mutation tool with no annotations and 0% schema coverage, the description omits the meaning of run_name, tree_file, and tree_content. An agent cannot reliably call it without guessing these inputs.

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% and there are 4 parameters. The description documents the structure of the colors entry (taxa/color/all) but says nothing about run_name, tree_file, or tree_content, leaving half the parameters undocumented in both schema and description.

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 ('Color') and resource ('a clade's MRCA branch' / 'all descendant branches'), and clarifies the all=false vs all=true distinction. It does not explicitly differentiate from close siblings like highlight_clade or style_tree, so it falls 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 all flag gives implied usage context (MRCA branch vs all descendants), but there is no guidance on when to use this versus highlight_clade or style_tree, nor any prerequisites. Usage is inferable but not stated.

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?

With no annotations, the description carries the full burden and does well: it discloses that strict raises 'validation_failed' on mismatch, that low_memory is effectively a no-op ('IDs are always read lazily'), and that sequences_file must be whitelisted and tree_file must live in an allowed read root. It adds real behavioral context beyond a bare statement, though it omits permission/auth details.

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 is front-loaded in a single sentence, then parameters follow in a clean Args block. Every line adds information (the low_memory note is especially economical), with no redundant 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?

Return values are covered by the output schema and all parameters are documented, but with 0 required parameters and two alternative tree inputs (tree_content vs tree_file) the description never clarifies that exactly one must be supplied or how they interact. That ambiguity is a real gap for correct invocation.

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, and it documents all five parameters with meaning: tree_content as Newick/Nexus content, tree_file as a path within an allowed read root, sequences_file's whitelisting requirement, strict's default and failure behavior, and low_memory's parity-only status. Only the mutual exclusivity/required-choice between tree_content and tree_file is left unstated.

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: cross-validating tree tip labels against sequence IDs. An agent can tell what it does, though it does not explicitly distinguish itself from the sibling validate_tree (which likely validates tree structure rather than trees vs. 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 never says when to use this vs. validate_tree, check_monophyly, or other validation siblings, and gives no prerequisites or exclusion conditions. The whitelist/read-root notes imply constraints but not 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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavioral context: it is low-level, performs structural-only conversion with no styling applied, and include_taxa_block defaults to true. However, it says nothing about input source precedence (tree_file vs tree_content), permissions, or failure behavior.

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 one-line summary followed by a compact Args list; little waste. The embedded newline formatting is slightly awkward but the content earns its place.

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 explained, and the schema/annotation profile is light. Still, the ambiguity between tree_file and tree_content is a real gap for a converter with four optional inputs.

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, yet it documents only include_taxa_block and run_name. The two most important inputs, tree_file and tree_content, are entirely unexplained, leaving the agent unable to choose between a file path and inline content.

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 (load and export) and resource (base FigTree-compatible Nexus), and explicitly bounds scope with 'structural conversion only, Newick → Nexus; no styling'. This distinguishes it from styling siblings like style_tree. It stops short of naming a sibling alternative, so it lands at a clear 4 rather than 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?

'Low-level' and 'structural conversion only ... no styling' imply when this tool applies (raw format conversion, not presentation), but no sibling alternative is named and no explicit when-not condition is given. Usage must be inferred.

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?

No annotations are provided, so the description carries the full burden. It implies a safe read-only operation ('Report', 'Returns') and discloses the scope of inspection (Java/jar availability, workspace root, allowed read-only roots), but never explicitly states that it is side-effect-free or what permissions it needs. Adequate but not rich.

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?

Two sentences, front-loaded with purpose, then the returned fields. Slightly list-heavy but every element is relevant to deciding whether to call it.

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 zero-parameter, read-only diagnostic with a defined output schema, the definition is essentially complete. The enumeration of return values partly duplicates the output schema, but the surrounding context (workspace root, read-only roots) is useful framing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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?

States a specific verb and resource ('Report the FigTreeKit-MCP runtime environment') that an agent can immediately distinguish from the tree-manipulation siblings. It doesn't explicitly contrast itself with those siblings, but the diagnostic purpose is unmistakable.

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 is only implied: an agent can infer this is a diagnostic/environment-check tool useful before or when troubleshooting other calls. There is no explicit when-to-use statement, no mention of prerequisites or of any alternative sibling (e.g. check_figtree, setup_figtree) that might also be relevant.

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?

With no annotations, the description carries the full burden. It does disclose a genuinely non-obvious destructive behavior — clear_existing wipes '[&!hilight=...]' comments already embedded in the tree text, not just pending annotations — which is exactly the kind of context an agent needs. It says nothing about how run_name/tree_file/tree_content interact, persistence, or side effects on other annotation state.

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 purpose is front-loaded in the first sentence and the Args block is efficiently ordered with the most complex parameter first. Minor verbosity in the clear_existing explanation, but every clause carries useful information.

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. However, for a mutation tool with zero annotations and a stated destructive capability, the absence of any description of run_name/tree_file/tree_content and how the tool resolves its target tree leaves a real gap.

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. It gives rich detail for `highlights` (entry keys taxa/color/width/offset, plus the integer-offset constraint) and explains clear_existing, but leaves run_name, tree_file, and tree_content entirely undocumented — three of five parameters have no semantics anywhere.

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 ('Add FigTree hilight annotations (background bands) to one or more clades'), and naming 'background bands' disambiguates the visual effect. It does not, however, differentiate itself from close siblings like color_clade, clear_annotations, or style_tree, so an agent must still infer which annotation tool applies.

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?

There is conditional guidance embedded in clear_existing ('Clear existing highlights before applying'), which tells the agent when that flag is appropriate. But there is no explicit when-to-use-this-vs-color_clade/style_tree routing, and no prerequisites described, leaving usage largely implied.

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?

With no annotations, the description carries the full behavioral burden. It discloses useful traits (colour post-processing applies only to raster formats, default timeout ~180s, jar auto-detection/default config), but omits side effects such as where artifacts are written, whether rendering is expensive/blocking, or permission needs for whitelisted paths.

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 is front-loaded in the first sentence, followed by a clean Args block; every line maps to a real parameter. Slightly terse for an 11-parameter tool but no wasted text.

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 needn't be detailed, yet the description still notes paths plus optional base64 preview. Parameter and behavioral coverage are adequate for a moderate-complexity render tool, leaving only usage routing unaddressed.

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% (properties carry only titles/defaults), so the description must compensate, and it does: all 11 parameters are explained, including precedence rules, raster-only post-processing, defaults, and the resolution order for jar_path/timeout.

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 (render) and resource (Nexus file / tree content) plus outputs and the rendering engine, so the agent knows exactly what it produces. It does not, however, differentiate itself from siblings like style_tree or run_figtreekit_cli, which also touch tree rendering/output.

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 only routing hint is that nexus_file 'takes precedence' over tree_content, which is an argument-precedence note rather than tool-selection guidance. There is no statement of when to choose this tool over style_tree, export_nexus, or run_figtreekit_cli.

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?

With no annotations, the description carries the burden and does meaningful work: it discloses 'no shell', output redirection into the run directory, and rewrite tracking in ``rewrites``, which an agent needs to interpret results. It omits permissions side effects and whether the run directory persists or is discoverable, keeping it below 5.

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 is front-loaded in the first sentence, and the Args block is terse and information-dense. No filler, though the docstring formatting is slightly redundant with the schema.

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 arbitrary-CLI tool with an output schema already covering return values, the description supplies the non-obvious pieces: placeholder substitution, redirection, rewrite disclosure, and defaults. It is essentially complete, though guidance on interplay with sibling tools is absent.

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 must compensate, and it does: each of the five parameters is explained, including the ``<input>`` placeholder rule linking argv to tree_content/input_file and the defaults for timeout and capture_tail_bytes. Minor gaps remain (e.g. what a 'whitelisted file reference' means).

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 ('Run the figtreekit CLI with arbitrary argv') plus scope qualifiers ('full CLI coverage; no shell'), making it clearly the raw escape hatch. It doesn't explicitly name a sibling like render_tree to contrast against, 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 tool implies general-purpose CLI coverage, but the description never says when to reach for this versus the many focused siblings (render_tree, collapse_clade, etc.) or when-not to use it. No prerequisites or exclusions are given.

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?

No annotations are provided, so the description carries the full behavioral burden. It documents the fonts value shape but says nothing about whether this mutates a persistent tree, what setup/run context is required, or what happens to existing label styling. For an unannotated mutation tool this is a substantial gap.

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?

Efficient single-sentence statement followed by a compact Args block with an inline example. Front-loads the purpose, and the font_style legend is useful, though the Args rendering is somewhat dense.

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 explained, but for a 4-parameter mutation tool with no annotations and 0% schema coverage, three parameters and all behavioral context are missing. The description is not complete enough to invoke the tool confidently.

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%, yet only the fonts parameter is explained (with an example and the font_style enum mapping). The run_name, tree_file, and tree_content parameters are undocumented in both schema and description, leaving their mutual exclusivity and purpose ambiguous.

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 (Set) with a resource (font name/style/size) scoped to a clear target (a clade's tip labels). This is distinguishable from siblings like color_clade and style_tree, though it does not explicitly name those 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?

The description only says what the tool does; it gives no when-to-use conditions, no prerequisites, and no mention of alternatives such as color_clade or style_tree. Usage is left entirely 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?

With no annotations, the description carries the full behavioral burden. It does disclose meaningful traits: a network download, a compile step, that jar_path is whitelisted and suppresses compilation, and that check_only suppresses both steps. It omits where artifacts are written, failure modes, and permission/network requirements, so it is adequate rather than rich.

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 opening sentence front-loads the core action, and the Args list is compact and scannable with zero filler. No wasted sentences, though the arg lines are terse enough to feel like schema restatement in places.

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 explained. For a tool that downloads and compiles, though, the description says nothing about dependencies required, environment assumptions, or what happens on a failed compile, leaving gaps an agent would need to discover by calling.

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, and it largely does: all three parameters are given semantics beyond their types (jar_path whitelisted and no-compile, check_only skips download/compile, verbose prints progress). It stops short of format examples or default-value restatement.

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: downloads or uses a provided JAR and compiles the patched FigTree JAR. An agent can distinguish it from siblings like check_figtree or get_environment, though the description never names or contrasts those alternatives explicitly.

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 Args block implies usage conditions (pass jar_path to skip compilation, set check_only to only verify dependencies), which is genuine conditional guidance. However, it never says when to prefer this tool over check_figtree or get_environment, nor what prerequisites (Java, network) are required.

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?

With no annotations, the description carries the full burden and does so well: it discloses execution ordering (plain annotations → taxonomy → collapse), the --color-all limitation that prevents exact CLI reproduction when mixing color and color_all, multi-tree styling/export behavior, and that a warnings entry is emitted when split/all cannot be reproduced. Auth, rate limits, and failure modes are not addressed, but the operational semantics are notably rich.

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 is front-loaded in the first sentence, followed by returns, then behavior. Prose is dense but each clause carries information. The 'Args: See the mapped parameter table...' sentence is low-value filler but not egregious.

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-value explanation is not required (though provided). However, for a 52-parameter, zero-schema-coverage tool with no annotations, the description is materially incomplete: it neither documents the parameters inline nor supplies the enum-like value spaces (layout, order, multi_tree, collapse_style, etc.), leaving an agent unable to invoke it correctly without external docs.

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?

52 parameters at 0% schema description coverage, and the description explicitly defers to an external file ('See the mapped parameter table in docs/tools_reference_EN.md'), which an agent cannot reliably resolve mid-call. Only a handful of parameters (multi_tree, seed) get inline meaning; the remaining ~50 remain opaque from both schema and description.

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+resource clearly: styles a tree via the full FigTreeKit parameter surface and exports a FigTree-compatible Nexus file. The output artifacts (file, cli_command, config_json, per-operation records) are named. It does not, however, explicitly differentiate itself from single-operation siblings like highlight_clade, color_clade, or collapse_rank, which overlap in function.

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 is implied rather than stated: the multi_tree semantics (first/last/random, seed for reproducibility) convey some when-to context, and 'every argument is optional' sets defaults. But there is no explicit guidance on when to choose this omnibus styling tool over the granular siblings (color_clade, collapse_rank, highlight_clade), nor any when-not conditions.

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?

With no annotations, the description carries the full burden, and it does disclose non-obvious behavior: it never errors on validation, returns a multi_tree_hint instead, and tree_file must live inside an allowed read root (an access constraint). It never states the read-only nature of the operation explicitly, which keeps it short of a 5.

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 purpose and the validate_tree exclusion, then a compact Args block. Every line adds meaning rather than restating the schema. Slightly verbose in splitting behavior into two sentences, but nothing is wasted.

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-value detail is correctly omitted. The non-error contract and multi-tree handling are covered. Minor gaps remain: no guidance on choosing tree_content vs tree_file, and no mention that all parameters are optional.

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 must compensate and it does: each of the 6 parameters is explained with meaning beyond the bare names. Notably it surfaces the 1..10000 range on tip_labels_limit, the allowed values for multi_tree (first|last|random|split|all, absent from the schema), and the 0-based nature of tree_index.

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+resource ('Parse and summarize a tree') and enumerates the outputs (format, counts, root state, branch stats), so the agent knows exactly what it gets back. It also explicitly distinguishes itself from the sibling validate_tree, which is the main source of confusion in this cluster.

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 an explicit when-not plus the alternative: 'Never fails on validation issues (use validate_tree for that)'. It also states the conditional routing behavior for a multi-tree file with no selection, so the agent knows this call is safe to make even with ambiguous input.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses truncation to the first 200 entries, that totals are always returned, and that file-based inputs require allowed read roots and whitelisting. However, it omits read-only safety, error behavior, and mutual exclusivity of tree sources.

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-loads the purpose and CLI equivalence, then adds a critical truncation note before the structured argument list. The content is efficient and earns its place, though the argument repetition is expected for a parameter list.

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 needn't be explained. The description covers arguments and truncation well, but for a 4-parameter tool with no schema descriptions and no annotations, it omits usage guidance and does not resolve how to choose between tree_file and tree_content or whether one is required.

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. It describes all four parameters with formats and constraints: Newick/Nexus content, path within an allowed read root, optional whitelisted CSV/TSV mapping, and a prefix:rank list. It does not clarify whether tree_file and tree_content are alternatives or requiredness.

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 action (report taxonomy completeness per rank) and output (list complete/incomplete/missing tips), with an equivalent CLI command for grounding. It does not explicitly differentiate from sibling tools like analyze_taxonomy, but the purpose is clear enough for an agent to select it.

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?

Provides no when-to-use guidance, no alternatives, and no clarification on when to prefer tree_file vs tree_content. Usage is implied only by the tool name and argument list, leaving selection between this and sibling tools 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the read-only nature ('no persistent artifact is written'), the shape of the result ('structured errors, warnings, format and counts'), and the constraint that tree_file must live 'inside an allowed read root'. It omits what happens when both content inputs are missing or how errors are categorized.

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-line purpose, then returns, then a compact Args block with one line per parameter. Slightly redundant that it repeats the return summary already covered by the output schema, but no sentence is wasted.

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 four-parameter, zero-schema-coverage, zero-annotation tool, this covers purpose, outputs, and each argument. An output schema exists so return values need no further detail; the remaining gap is the mutual-exclusivity/inference rule between tree_content and tree_file.

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 must compensate, and it documents all four parameters: tree_content as direct paste, tree_file as a path under an allowed read root, mol_type with an inline enum (DNA|RNA|protein) not present in the schema, and skip_length_check tied to the FASTA alignment-length check. It still leaves the content-vs-file precedence rule unstated.

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 ('Deep-validate') and resource ('Newick/Nexus tree or FASTA/FASTQ sequence file'), and distinguishes itself from run_figtreekit_cli by noting it writes no persistent artifact. It does not, however, differentiate itself from the closely named sibling check_figtree, which is the most likely source of misselection.

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 note that semantics match ``figtreekit --validate`` with no artifact written implies when this is preferable to the CLI tool, but it never states when to choose validate_tree over check_figtree or cross_validate, or what to do if no input is supplied. Usage is implied rather than explicit.

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