taxonomy_completeness

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.