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 discloses the output contents (lineage, LCA, differing ranks, metrics), which is genuinely useful, but says nothing about permissions, error cases (e.g., mismatched or missing genomes), or result size/limits. The operation is obviously a non-mutating read, so the safety gap is minor, but the completeness gap is real.

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 tight sentences with zero filler. The purpose is front-loaded and the return summary follows immediately, each sentence earning 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?

With no output schema, the description usefully enumerates the return fields, and a two-parameter read tool needs little else. It stops short of covering failure modes or edge cases (missing/invalid genome IDs, cross-domain comparison behavior), 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 coverage is 100%: both gid1 and gid2 are documented with example accession formats directly in the schema. The description adds only that the arguments are genomes being compared; it contributes no format, ordering, or constraint detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Compare two genomes taxonomically') and enumerates exactly what is computed (shared lineage, LCA, differing ranks, metric diffs). This cleanly distinguishes it from single-genome siblings like get_genome, get_taxonomy, and get_tree_path.

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 strongly implied by the comparative framing — an agent can infer this is the tool for pairwise genome comparison versus the single-entity siblings — but there is no explicit when-to-use, when-not, or named alternative. Adequate but with a clear gap.

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 exist, so the description carries the full burden. It discloses the one-level (direct) semantics and the shape of the result (child taxon names), but says nothing about read-only safety, case sensitivity of the name, empty results, or error behavior for an unknown taxon.

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 tightly written sentences with the core action front-loaded and the example placed after it for illustration. Nothing is wasted and no filler is present.

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 simple single-parameter lookup with no output schema and no annotations, the description covers what the tool does and the form of the return values. Only the boundary behaviors (unknown taxon, non-matching name) remain unaddressed, which is minor for this tool class.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'name' parameter is already documented in the schema. The description's examples ('Bacillales') reinforce but add no syntax or constraint detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Get') + resource ('direct child taxa') + scope ('in the GTDB taxonomy'), with a concrete example naming real children of 'Bacillales'. This clearly distinguishes it from siblings like get_taxonomy, get_taxon_summary, and get_tree_path.

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 word 'direct child' implicitly scopes the request (one level, not the full subtree), which helps the agent choose it over deeper-traversal siblings. However, no explicit when-to-use, when-not, or named alternative is 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 must carry the behavioral burden. It discloses the content returned and the tool takes no parameters, making its read-only, side-effect-free nature self-evident, but it says nothing about cost of computing diversity metrics, caching, or freshness of the release 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?

A single front-loaded sentence that identifies the resource first and then lists the returned metrics. Every clause carries information and 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?

With no output schema, the description must convey the return content, and it does so by enumerating version, release date, counts, and diversity metrics. It stops short of indicating the shape or naming of those metrics, which would help an agent parse results, but the essentials are covered.

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 has zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4. The description correctly makes no parameter claims and focuses on output content instead.

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 names a specific verb+resource ('Get statistics about the GTDB database') and enumerates the content returned: version, release date, genome counts, and taxonomic diversity metrics for bacteria and archaea. No sibling tool (search, get_taxonomy, compare_genomes, etc.) overlaps with this purpose, so it is unambiguously distinguishable.

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 — an agent should call this when it needs database version or aggregate counts — but the description never states when to use it versus navigating the taxonomy with get_taxonomy or get_taxon_summary. For a zero-parameter tool this is a minor gap, yet no explicit context or exclusion is 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the return payload (taxonomy, genome size, GC content, quality metrics, type strain status), which is valuable since no output schema exists. It does not state read-only semantics explicitly or describe behavior for an unrecognized/invalid genome ID.

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, zero filler, with the purpose and lookup key front-loaded before the return-field enumeration. Every clause 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?

For a single-parameter read lookup with no output schema, the description covers the return fields an agent would need to know and the required identifier format. The only real gap is error behavior for invalid IDs, which is minor here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter's description already supplies the same example identifiers ('GCF_000005845.2', 'GCA_000091565.1') that the tool description repeats. The description therefore adds no meaning beyond the schema, matching the baseline 3.

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 (Get) and resource (genome), and pins the lookup key as a GTDB genome ID, which implicitly separates it from ID-less siblings like list_phyla or get_genomes_for_species. It does not explicitly name an alternative, so it stops short of full 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?

Usage is only implied: the agent can infer this is the tool to reach for when it already holds a genome ID rather than a species or taxon name. There is no explicit when-to-use statement, no when-not-to-use, and no sibling named as an alternative.

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 read-only operation via 'Get' and clarifies the data scope, but does not state return format, pagination behavior, or explicitly confirm no side effects.

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 the core action and immediately followed by the main use case. No filler or redundancy; every sentence 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?

For a low-complexity, single-parameter lookup with full schema coverage and no output schema, the description is largely complete. It misses explicit routing to get_genomes_for_taxon for broader queries, but otherwise covers purpose and usage adequately.

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 single 'species' parameter is fully documented in the schema with examples, so the schema already carries the semantic load. The description adds no additional parameter meaning beyond what the schema provides, matching the baseline 3 for high coverage.

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 ('Get all genome assemblies'), scoped to a species in GTDB. An agent can distinguish it from get_genome (single genome) and get_genomes_for_taxon (higher taxonomic level) without inspecting 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?

Provides a clear use case ('finding reference genomes and type strains'), which gives useful context for when to call it. However, it does not name alternatives or state when not to use it (e.g., for broader taxa).

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, yet it says nothing about result ordering, truncation behavior, pagination, or that results are capped by the limit parameter. For a listing tool whose default silently returns only 100 IDs, that silence is a meaningful 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?

Two tight sentences with the core purpose front-loaded and a single illustrative clause that earns its place by clarifying taxonomic scope. 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?

For a simple two-parameter lookup this is largely adequate, but with no output schema and no annotations the description should at least indicate what is returned (genome IDs/accessions) and how the limit interacts with large taxa. The current text leaves that to the schema's terse parameter description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema, and the baseline is 3. The description's taxon examples ('Enterobacteriaceae', 'Bacillota') reinforce the expected value format but add little beyond what the schema already states.

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 ('Get all genome assemblies classified under a given taxonomic group') and grounds it with concrete examples at family and phylum rank. It implicitly distinguishes itself from the species-level sibling, but never names get_genomes_for_species or other alternatives explicitly, 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 examples ('family Enterobacteriaceae or phylum Bacillota') imply the intended granularity of use, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as get_genomes_for_species or get_taxon_summary. Usage is inferable 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return structure (d__; p__; c__; o__; f__; g__; s__ lineages), which compensates for the missing output schema, but says nothing about behavior for unknown/nonexistent taxa, name-matching rules, or whether ambiguous names resolve to multiple lineages.

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 the core action and resource, and the parenthetical lineage format is a justified elaboration given the absence of an output schema. 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?

For a one-parameter, no-annotation tool with no output schema, the description adequately covers the return shape (lineage ranks). It falls short only on failure/edge behavior and sibling differentiation, which are minor gaps for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and includes concrete examples for the single 'name' parameter, so the schema does the heavy lifting. The description adds only the notion that name may be an organism or taxon, no format or resolution details beyond the schema examples.

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 (Get) and resource (complete taxonomic lineage) plus the data source (GTDB), and specifies scope from domain to species. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling get_taxon_summary or get_tree_path.

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 says what can be fetched but gives no explicit when-to-use guidance, no conditions distinguishing it from get_taxon_summary or get_tree_path, and no prerequisites or exclusions. Usage is only inferred from the purpose.

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 disclosure burden. The 'Get' prefix and summary framing imply a read-only aggregation, and it discloses what categories of data are returned, but it says nothing about permissions, rate limits, or whether counts are cached/approximate.

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 the core action and returned fields, with no redundant restatement of the name. The closing benefits sentence is mildly generic but still adds usage signal.

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 no output schema, the description appropriately enumerates the return contents (genome counts, species counts, child taxa, description), which is what an agent needs to decide to call it. The absence of annotations leaves permission/safety behavior unspecified, a minor gap for a read-style tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents the single 'name' parameter with concrete taxon examples (Bacillota, Gammaproteobacteria, etc.). The description adds no format or level-specific semantics beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('summary of a taxonomic group') and enumerates the returned content (genome counts, species counts, child taxa, description). It does not explicitly contrast itself with close siblings like get_taxonomy or get_children, so an agent must infer the distinction from the 'comprehensive summary' framing.

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 second sentence gives a reason to call it ('understanding the diversity and composition of any taxonomic level'), which implies usage but names no alternatives and provides no when-not conditions. There is no guidance on choosing it over get_taxonomy or get_children.

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 discloses the conceptual return (the route via LCA), which is useful, but says nothing about permissions, whether it is a pure read, or how the path is formatted/ordered. The verb 'Get' weakly implies read-only, but nothing is confirmed.

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 tight sentences with zero filler, front-loaded with the core action and followed by a clarifying mechanism. Every clause 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?

For a two-parameter read query with no output schema and full schema coverage, the description is nearly complete — it explains both the action and the conceptual result. Only the concrete output shape and ordering are left unstated, which is a minor 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 100% (both params documented as 'Starting taxon name' and 'Ending taxon name'), so the baseline is 3. The description reinforces directionality with 'from one taxon to another' but adds no syntax, format, or naming conventions beyond what the schema already supplies.

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 (get tree path between two taxa) and clarifies the mechanism — the route through the taxonomy tree via the lowest common ancestor. This is far more informative than a tautology, though it never explicitly names a sibling to contrast with (e.g., get_children or get_taxonomy), so sibling differentiation is left implicit.

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 the tool applies — computing a relationship between two taxa rather than fetching one node — but gives no explicit when-to-use guidance, no exclusions, and no named alternatives. Usage must be inferred from the purpose statement.

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. 'List' plus the read-only nature of taxonomy browsing makes the safety profile reasonably clear, but it says nothing about ordering, result volume, or what the entries look like when returned.

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 tight sentences with the core action front-loaded and the positional hint second. Nothing is padded or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, fully documented, read-only listing tool with no output schema, the definition covers what an agent needs: what it returns conceptually and that it operates at the root of the taxonomy. A note on how the returned phyla feed into other tools would make it 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 100% and the single domain parameter has an enum plus an 'If omitted, lists all phyla' note, so the schema already does the work. The description only echoes the Bacteria/Archaea choice without adding format or behavior detail beyond it.

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 gives a specific verb and resource ('List all bacterial or archaeal phyla in GTDB') and states its position as the top-level entry point, which helps separate it from get_children and list_taxa_by_rank. It is clear, though it does not explicitly name the sibling tools that cover other ranks.

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?

'This is the starting point for exploring the taxonomy tree from the top level' implies when to reach for it, but no alternatives or exclusions are named (e.g. when to prefer list_taxa_by_rank or get_children for deeper levels). Usage is inferable but not spelled out.

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, and it discloses almost nothing: no mention of result volume, pagination, ordering, or return shape for what could be a very large listing. The read-only nature is only inferable from the word 'list'.

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 tight sentences, front-loaded with the core action and constraint. The trailing 'useful for browsing' clause is mildly filler but does add usage framing.

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 simple two-parameter read tool this is close to adequate, but with no annotations and no output schema the description leaves out anything about result size or pagination, which matters for a 'list all' operation. Minimum viable rather than 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 100% and both parameters carry enums with descriptions, so the schema already does the work. The description restates rank and the optional domain filter without adding format, default, or interaction semantics. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list) and resource (taxa at a given rank) with scope ('all taxa'). However, it never differentiates itself from the sibling list_phyla, which would be an obvious overlap when rank='phylum', nor from get_children.

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?

'Useful for browsing the taxonomy at any level' implies a browse/discovery use case but names no alternative and gives no when-not condition. An agent choosing between this, list_phyla, and get_children gets no routing help.

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 supplied, so the description carries the full burden. It does disclose useful behavior: partial matching with a worked example, and the three result categories returned. It is silent on read-only semantics, rate limits, pagination beyond the schema's limit field, and result ordering, which for a search endpoint is a real but modest 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?

Three short sentences, front-loaded with the core action, followed by return scope and the one non-obvious behavior (partial matching). No filler, no restatement of the title, and the partial-match note is placed exactly where an agent would need 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?

With no output schema and no annotations, the description does the needed work: it names the database, the matching mode, and the three families of results an agent will get back. Parameter documentation is fully carried by the schema, so the only remaining gap is the absence of any routing guidance relative to the many sibling retrieval tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema, which sets the baseline at 3. The description reinforces query semantics by clarifying that matching is partial with concrete examples, but adds no new syntax, format, or limits information beyond what the schema already provides.

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 (search) and resource (taxa or genomes in the GTDB database) and adds the return scope (matching organisms, taxonomic groups, genome assemblies). Among eleven siblings it is unmistakably the only discovery-by-name tool, so no schema opening is needed to tell it apart from get_taxon_summary or get_children.

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 usage through the query forms it accepts ('Escherichia coli', 'Bacillus', a genome ID) and the partial-match behavior, but it never states when to prefer this tool over siblings such as get_taxon_summary or get_genomes_for_species, nor when it should not be used. Usage is inferable rather than spelled out.

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