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 need for ENV variable, return format (raw string), and mentions NCBI blocking possibility. It lacks details on rate limits, error handling, or empty results.

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

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

The description is long but well-structured with sections (Critical Configuration, Parameters, Returns, Example). It contains some redundancy (e.g., 'This tool is designed to be called...'). Could be more concise without losing clarity.

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

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

Given the tool has 3 parameters, no annotations, and an output schema (though not provided), the description covers essential aspects: parameter details, configuration, return value type, and an example. It is complete enough for an agent to use correctly.

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% (no descriptions in schema). The description compensates with detailed explanations: ids (list with example), db (enum with common choices and caution), reftype (two literals with format descriptions). This adds significant meaning beyond the schema.

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

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

The description clearly states the tool downloads data from NCBI Entrez databases using Bio.Entrez. It uses specific verb (download) and resource (Entrez databases). However, it does not differentiate from the sibling tool 'biothings_download_entrez_data_local'.

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 provides critical configuration requirements (ENTREZ_EMAIL) and an example, but does not explicitly state when to use this tool versus alternatives (e.g., local version). No exclusions are mentioned.

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 provided, the description carries the full burden. It discloses the behavior of saving to a local file, the output structure (LocalFileResult with path, format, success, error), and mentions that if output_path is None, a unique filename is generated. It does not mention potential side effects like overwriting files, but the unique filename generation mitigates that. The description adequately covers the core behavioral trait.

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 well-structured with clear sections for description, parameters, returns, and example. It front-loads the core purpose and sibling differentiation in the first two sentences. Every sentence adds value, and the example code block is concise.

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

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

Given the tool has 4 parameters and a sibling tool, the description covers all necessary aspects: core action, differentiation from sibling, parameter details, return structure, and usage example. No gaps remain for the agent to make an informed decision.

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 so excellently: each parameter is listed with type, requirement, and for db and reftype, the enum values are referenced. It explains the behavior of output_path (optional, custom path or unique filename). An example usage is provided that ties all parameters together.

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

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

The description clearly states the action: 'Download data from NCBI Entrez databases and save to local file.' It immediately distinguishes itself from the sibling tool biothings_download_entrez_data by explaining that this version saves to a file instead of returning content.

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 explicitly states when to use this tool: 'useful for large downloads or when you want to persist the data.' This implies when not to use it (when you want the content directly), effectively guiding the agent to choose between the two sibling tools.

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

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

No annotations are provided, so the description must fully disclose behavior. It lists the types of information returned (structural, physical, chemical, stereochemistry, identifiers) but does not mention side effects, authentication, rate limits, or error handling. Adequate but not comprehensive.

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 purpose but includes a bullet list of ID formats and return categories that could be more concise. It is somewhat wordy for the value added.

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 existing, return value documentation is covered. However, the description omits details for two parameters (email, fields), making it less complete for a tool with 3 parameters.

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%. The description only explains the chem_id parameter with examples, leaving email and fields completely undocumented. This fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the verb 'Fetch' and the resource 'specific chemical compound by ID', supported by examples of ID formats. It distinguishes from sibling tools like biothings_get_chems (plural) which imply batch retrieval.

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 single-compound retrieval but does not explicitly state when to use it over alternatives like biothings_query_chems or biothings_get_chems. No exclusions or alternative guidance provided.

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. It indicates a read operation (fetch) but does not disclose what happens with invalid IDs, rate limits, or authentication needs.

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 relatively concise with a clear structure including an Input Format subsection. However, it contains slight redundancy ('Retrieves information' repeats the purpose).

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?

Despite an existing output schema, the description lacks guidance on optional parameters (email, fields) and does not mention pagination or response shape. It is adequate but incomplete.

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%. The description adds meaningful context for chem_ids (formats, examples) but does not explain email or fields parameters, nor their possible values.

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

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

The description clearly states the tool fetches multiple chemical compounds by a comma-separated list of IDs. It distinguishes from biothings_get_chem (singular) and provides specific input format examples.

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 use when you have a list of IDs but does not explicitly contrast with alternative tools like biothings_query_chems or provide conditions for when not to use it.

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 provided, but the description discloses that it retrieves detailed info for a single gene. It lacks details on error handling or rate limits, but the non-destructive read-only nature is clear from the description.

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?

Description is concise, uses bullet points and bold for readability. It front-loads the purpose and is not overly verbose. Minor room for improvement by explaining additional parameters concisely.

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?

Output schema exists, so return values are covered. However, the description lacks explanation for three of four parameters, which reduces completeness for a tool with moderate complexity.

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 the description only explains the 'gene_id' parameter with examples. Other parameters ('email', 'fields', 'species') are not mentioned, leaving gaps.

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

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

The description clearly states it fetches a specific gene by Entrez or Ensembl ID. It uses a specific verb and resource, and distinguishes from sibling tool 'query_genes' by highlighting it is preferred when you already know the ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: when you have a known standard ID and don't need complex search filters. Also mentions it's preferred over 'query_genes', providing clear usage 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 full burden. It describes the return structure (stats, fields, index, version) and clarifies it is metadata, not gene data. However, it does not disclose other behavioral traits such as rate limits, authentication requirements, or side effects, leaving some gaps.

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 well-structured: a concise first line, a bold warning for clarification, and a bullet-pointed list of returned information. Every sentence adds value without redundancy.

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 metadata tool with a single optional parameter and an output schema, the description covers the main purpose and return values adequately. However, it lacks explanation of the email parameter and does not mention any limitations or when this tool is preferred over other sibling 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?

The input schema has 1 parameter (email) with 0% schema description coverage. The description does not mention the email parameter at all, failing to explain its purpose or semantics. With low coverage, the description should compensate but does not.

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

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

The description clearly states it retrieves MyGene.info database metadata including stats and fields, and explicitly distinguishes this from retrieving specific gene data. The verb 'retrieve' and resource 'database metadata' are specific, and the description highlights that it is NOT for specific genes, effectively differentiating it from sibling tools.

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 explicitly states 'Use this tool ONLY to understand the database itself' and 'It CANNOT be used to find or retrieve data for any particular gene.' This provides strong guidance on when to use and when not, but it does not name specific alternative tools for gene data retrieval, which would improve clarity.

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 states that the tool retrieves detailed information in a single request and provides input format examples, but it does not disclose error handling, limits on ID count, authentication needs, or output structure beyond 'detailed information'. The existence of an output schema is noted but not detailed.

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

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

The description is short and front-loaded with the core purpose. It uses bold for emphasis and provides a clear example. A minor inefficiency: repeating the input format explanation could be streamlined.

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?

Despite having an output schema and four parameters, the description only covers one parameter and omits details on output format, allowed values for 'fields', default behavior for 'species', and any constraints. This leaves the agent with insufficient context to use the tool correctly.

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 only explains the 'gene_ids' parameter with format and examples. The 'email', 'fields', and 'species' parameters are completely undocumented, leaving significant ambiguity for the agent.

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 ('fetch') and resource ('multiple genes'), and explicitly distinguishes itself from the sibling tool 'query_many_genes', making its purpose very clear.

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 provides explicit guidance on when to use this tool ('when you already know their standard IDs and don't need complex search filters') and directly names the alternative tool ('query_many_genes').

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 fully carries behavioral disclosure. It explains that the tool returns comprehensive taxon information, lists included categories (basic info, classification, lineage, etc.), and mentions supported identifier types. It lacks mention of authentication or rate limits, but for a read-only tool this is adequate.

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 well-structured with clear sections and bullet points. It efficiently conveys key information without extraneous text. Every sentence adds value.

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

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

Given the presence of an output schema, the description need not detail return values but does so helpfully. The description covers the main use case and parameters adequately but could mention the optional 'email' parameter for rate limiting or the 'fields' parameter options. Still, it is largely complete for a single-resource fetcher.

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

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

With 0% schema description coverage, the description must compensate. It thoroughly explains the main parameter 'taxon_id' with examples and accepted formats. However, it does not describe the 'email' and 'fields' parameters, leaving some ambiguity. The 'fields' default is 'all' but allowed values are unspecified. Thus it adds value but incompletely.

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 explicitly states the tool fetches a specific taxon by NCBI ID or scientific name, with concrete examples (e.g., 9606 for Homo sapiens). It clearly distinguishes from sibling tools like biothings_get_taxons (plural) which handles multiple taxa.

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 clarifies when to use this tool (for a single taxon lookup) and implies that for multiple taxa one should use biothings_get_taxons. However, it does not explicitly state when not to use it or provide alternative tools, which would strengthen 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 burden. It states it retrieves information for multiple taxa in a single request and gives format examples. However, it does not disclose error handling (e.g., partial failures), rate limits, authentication, or what happens with invalid IDs, leaving gaps in behavioral understanding.

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 main purpose and includes helpful examples. At 10 lines, it is slightly verbose but each sentence adds value. It is well-structured and easy to scan.

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 are covered. The description explains the required parameter well but omits details about optional parameters (email, fields) and their defaults. For a simple fetch tool, it is moderately complete but could be improved.

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 schema has 3 parameters (email, fields, taxon_ids) with 0% description coverage. The description adds meaning to 'taxon_ids' by specifying comma-separated format and examples, but does not explain 'email' or 'fields'. Thus, it partially compensates for the schema's lack of descriptions.

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

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

The description clearly states 'Fetch multiple taxa by a comma-separated list of NCBI IDs or scientific names,' specifying the action, resource, and input format. It distinguishes itself from siblings like 'biothings_get_taxon' (singular) and 'biothings_query_taxons' (likely query-based).

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 provides explicit input format and examples, making it clear when to use the tool (fetching multiple taxa by IDs/names). It does not explicitly state when not to use it or mention alternatives, but the sibling tool names imply singular vs plural and fetch vs query distinctions.

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 that the tool retrieves detailed annotation data, which implies a read operation. It also notes the hg19 base for HGVS IDs, a useful behavioral nuance. However, it does not mention any authorization requirements, rate limits, or that it is a read-only operation explicitly.

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 well-structured with sections and bullet points, making it easy to scan. It is concise but contains some redundancy (e.g., repeating 'specific variant' multiple times). Overall, it is efficient and front-loaded.

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 that an output schema exists (not visible) and the tool has 3 parameters, the description covers the main purpose and the key parameter well. However, the lack of documentation for `email` and `fields` reduces completeness. For a single-variant fetch tool, it is adequate but not fully comprehensive.

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%, but the description only explains the `variant_id` parameter with examples and notes. The `email` and `fields` parameters are completely undocumented in the description, leaving the agent without guidance on how to use them.

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 explicitly states it fetches a specific variant by HGVS or rsID, and distinguishes itself from the sibling tool `query_variants` by emphasizing it is for single, specific identifiers. The verb 'Fetch' and resource 'variant' are clear, and the scope is well-defined.

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 provides explicit usage guidance: 'This is the preferred tool over query_variants for fetching a specific variant when you already know its standard ID.' It also lists supported identifiers, giving clear context for when to use this tool instead of alternatives.

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 full burden. It states retrieval of annotation data and input format, but omits behaviors like required authentication, rate limits, handling of invalid IDs, or maximum number of variants per request. Output schema exists but description doesn't hint at response structure. Gaps in behavioral context.

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?

Description is relatively short and front-loaded with the core purpose. Uses bullet-style formatting for examples. Could be slightly more concise by removing redundant phrasing, but overall efficient.

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

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

Given the output schema exists, return values need no explanation. However, the description lacks details on the optional parameters (`email`, `fields`) and does not discuss behavior limits or error handling. The variant_ids parameter is well-covered, but the tool's overall context is incomplete for a tool with 3 parameters and 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 description must compensate. It thoroughly explains the `variant_ids` parameter format with examples, but provides no information on `email` or `fields` parameters. Adds meaning beyond schema only for one of three parameters, leaving others undocumented.

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

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

The description clearly states 'Fetch multiple variants by a comma-separated list of HGVS or rsIDs', specifying the verb and resource. It distinguishes itself from the sibling tool `query_many_variants` by noting it is preferred when standard IDs are known, providing strong 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?

Explicitly says 'This is the preferred tool over query_many_variants for fetching multiple specific variants when you already know their standard IDs (HGVS or rsID).' This gives clear guidance on when to use this tool versus the alternative, and includes input format examples.

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 burden. It discloses that the tool performs a search and returns compound details with PubChem fields, but fails to mention rate limits, authentication, pagination behavior, or whether the operation is read-only (likely safe). It adds some context beyond the schema but is not exhaustive.

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 moderately concise with a summary and list of query features. However, the repeated mention of PubChem data is somewhat redundant. It could be more streamlined.

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

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

Given the 6 parameters and existence of an output schema, the description covers only the query string aspect thoroughly. It fails to explain other parameters, response format, or sibling tool differentiation. The tool is moderately complex but the description leaves significant gaps.

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%, requiring full compensation. The description only explains the 'q' parameter with examples; the other five parameters (size, skip, sort, email, fields) are not described at all. This is insufficient for a 6-parameter tool.

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

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

The description clearly states it searches chemical compounds via Lucene query and returns compound details and metadata. It specifies the resource (chemical compounds) and action (search), but does not explicitly differentiate from sibling tools like biothings_get_chems or biothings_query_genes.

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 provides extensive query syntax examples but offers no guidance on when to use this tool versus alternatives like biothings_get_chem or biothings_query_many_chems. It lacks prerequisites, context for when not to use, or differentiation from similar search tools.

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

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

No annotations provided, so description carries full burden. It discloses that queries must be structured Lucene queries, lists supported query features, and mentions return fields. However, it does not discuss rate limits, authorization, or 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?

Description is well-structured with bold warnings, bullet points for query features, and clear examples. It is informative but not excessively long. Minor redundancy could be trimmed.

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 7 parameters and an output schema, the description covers the critical 'q' parameter thoroughly but leaves other parameters unexplained. Output schema handles return values, but parameters like sort, fields, email need more context.

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%. Description adds significant value for the 'q' parameter with examples, but provides minimal guidance for other parameters like size, skip, sort, fields, email, and species. Partially compensates.

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

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

The description clearly states the tool searches genes via Lucene query and returns gene details and metadata. It uses a specific verb 'search' and resource 'genes', and distinguishes from sibling tool 'biothings_get_gene' for exact IDs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (searching by criteria) and when not to use (exact ID known, use get_gene instead). Warns against natural language queries and provides examples of correct query syntax.

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 burden. It discloses the batch nature and supported queries but lacks mention of behavioral traits like whether it is read-only, authentication needs, rate limits, or error handling. The description is insufficient for full transparency.

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 reasonably concise and front-loads the purpose. It uses bullet points for structure, though some text could be tightened. Overall, it is efficient and well-organized.

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

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

Given the tool's complexity (4 parameters) and presence of an output schema, the description covers the key aspects: batch query, supported query types, parameter usage. It does not discuss errors or output details, but the output schema exists to fill that gap. It is complete enough for a query 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 0%, so the description must compensate. It explains the main parameter 'query_list' with examples, and describes 'scopes' and 'fields' with usage context. Only the 'email' parameter is not discussed. This adds significant meaning beyond the schema.

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

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

The description clearly states it performs batch queries of chemical compounds by multiple terms, with examples. It distinguishes from siblings like biothings_get_chem and biothings_query_chems by explicitly mentioning 'batch' and 'multiple terms', but could more directly contrast with those tools.

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 provides supported usage scenarios (multiple query types, field scoping, result filtering) but does not explicitly state when to use this tool versus alternatives or when not to use it. The usage guidance is implied through examples.

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 explains the core behavior (batched search, comma-separated terms, scopes) but does not disclose potential limitations such as rate limits, error handling for invalid terms, or authentication requirements. Thus, transparency is adequate but not thorough.

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 concise, with two paragraphs and bullet examples. It front-loads the purpose. A slight redundancy exists in the first paragraph (repeats 'batch query' idea), but overall it's efficient.

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?

The description provides enough context for using the tool with required parameters and common optional ones, but does not cover all parameters (size, email, species) or error scenarios. Given the output schema exists, return values are not needed, but the description could be more complete regarding optional fields and behavior on failure.

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 explains query_list (comma-separated terms) and scopes (fields to search against) with examples, and hints at fields via default 'all'. However, it does not explain size, email, or species parameters. Overall, it adds meaningful context for the essential parameters but misses several.

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

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

The description clearly states that this tool performs batch queries for multiple gene terms and returns a list of gene details. It explicitly distinguishes itself from the sibling tool query_genes by noting that query_list takes multiple terms rather than full query strings, and provides concrete examples (e.g., CDK2,BRCA1).

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 includes explicit usage guidelines: it contrasts with query_genes, explains when to use this tool (for multiple terms), and provides endpoint usage examples with different scopes. This helps the agent choose correctly among siblings.

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 full burden. It only states the tool performs multiple queries and gives examples, but does not disclose behavioral traits such as query limits, case sensitivity, partial match handling, or whether it is read-only. This lacks sufficient transparency for a batch query tool.

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

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

The description is moderately sized and well-structured with a brief intro and bullet points. It is front-loaded with the main purpose. Some sentences could be trimmed, but overall it is clear and easy to scan.

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 4 parameters, no annotations, and an output schema, the description covers major usage patterns but omits details on query_list format and email parameter. The complexity warrants more complete guidance, especially for a tool that expects a list-like input as a string.

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 compensates by explaining the usage of scopes and fields parameters with concrete examples. However, the email parameter is not mentioned, and the query_list parameter format (JSON array as string) is not clarified. Still, it adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool performs batch queries for taxa using multiple terms, with specific examples of scientific and common names. It distinguishes itself from sibling tools like biothings_get_taxon by emphasizing batch capability and multiple query types.

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 provides explicit usage scenarios: multiple query types, field scoping, and result filtering. It implies use for batch queries but does not explicitly mention when not to use or compare to biothings_query_taxons, though sibling names provide some context.

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 fully disclose behavior. It explains the batch query mechanism and scope usage, but omits details on error handling, rate limits, or response structure.

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 moderately concise, using bullet points and examples efficiently, though it could be organized more tightly.

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 there is an output schema and no annotations, the description covers the core functionality and parameter usage, but lacks behavioral details and full parameter explanations, leaving some gaps for a 4-parameter 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 coverage is 0%, so the description should explain each parameter. It elaborates on query_list and scopes via examples, but does not clarify email or fields (defaults are mentioned but not explained).

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

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

The description clearly states the tool performs batch queries for multiple variant identifiers (rsIDs, HGVS IDs) and distinguishes itself from siblings like biothings_get_variant by emphasizing multiple terms in a single request.

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 provides examples of when to use the tool (e.g., multiple rsIDs, HGVS IDs), but does not explicitly compare to sibling tools like biothings_query_variants or state when not to use it.

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 all behavioral traits. It describes query types but omits safety (read-only), rate limits, authentication needs, or error handling. The description is honest but incomplete for non-query 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?

The description is well-structured with headings and bullet points, front-loading the purpose. It is informative but could be slightly more concise by trimming redundant phrasing like 'Search for taxa using a query string with various filtering options.'

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 6 parameters and an output schema, the description fails to document pagination (size, skip), sorting (sort), fields selection, or output structure beyond 'taxon details and query metadata.' This leaves the agent underinformed for effective 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. Only the 'q' parameter is explained with examples; 'size', 'skip', 'sort', 'email', and 'fields' are not described, leaving significant gaps in parameter understanding.

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

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

The description clearly states the tool searches taxa via Lucene query, returning taxon details and metadata. It distinguishes from sibling tools like biothings_get_taxon (retrieval by ID) and biothings_query_many_taxons (batch query) by emphasizing query flexibility.

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 for complex, fielded, or boolean queries but does not explicitly state when to use this tool vs alternatives (e.g., get_taxon for known IDs). No when-not guidance or exclusion criteria are provided.

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 description carries full burden. It discloses API dependency (MyVariant.info) and Lucene query features. Could mention pagination or rate limits but is quite transparent for a search tool.

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

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

Well-structured with bullet points for query features. Each sentence adds value, no fluff. The description is appropriately sized for the complexity.

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?

Output schema exists. Description covers query capabilities thoroughly and references the API. Could mention how to use 'fields' to restrict output and explain pagination parameters, but overall sufficient for a search 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 coverage is 0%. The description only explains the 'q' parameter with examples. Other parameters like 'size', 'skip', 'sort', 'email', 'fields' are not described. Partial compensation, but significant gaps remain.

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

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

The description clearly states it searches variants via Lucene query and returns variant details and query metadata. It distinguishes itself from the 'get_variant' tool by specifying when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this tool for *searching* variants based on criteria' and recommends 'get_variant' for exact IDs, providing clear when-to-use guidance.

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