ena_sequence_search

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

Since no annotations are provided, the description carries the full behavioral burden. It does disclose useful behavior: the search scope, the ability to use tax_tree syntax, and the fields returned. It does not mention pagination behavior, matching semantics, authentication needs, rate limits, or result size constraints, which leaves notable gaps for a tool with no annotation safety net.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and remains fairly short. However, it repeats nearly the same information in English and Chinese, and the bilingual duplication adds length without much new meaning for an agent. It is adequate but not maximally economical.

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 the explicit return-field list is somewhat redundant, and the description gives enough query context and examples to make a valid first call. The main omissions are max_results behavior and pagination details, and there is no pointer to sibling tools for related sequence searches. This is acceptable but not high-confidence completeness for a tool with no annotations.

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 does a reasonable job for the required query parameter by explaining that it accepts species names or keywords and by giving valid ENA query syntax examples. It does not explain max_results semantics or any bound, though the parameter name and default make its basic intent guessable.

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 resource and operation: 'Search EBI ENA nucleotide sequences' with a microbial/viral/plasmid scope, and it lists the returned fields (accession/description/organism/tax_id). This makes the tool's function immediately identifiable and separates it from clearly unrelated siblings. However, it does not explicitly contrast it with the closest sequence-search siblings such as ncbi_fetch_sequence or blast_search, so it stops just short of full 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?

The description implies when to use the tool by saying it accepts species names or keywords and by giving concrete examples like tax_tree(562) and tax_tree(2697049). It also states the general purpose, 'for microbial and nucleic acid research.' It never gives when-not-to-use guidance or names alternative tools, leaving the agent to infer routing from the ENA-specific wording.

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