BioMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation2/5
Multiple tools have nearly interchangeable roles, especially biogrid_interactions vs. biogrid_gene_interactions, hgnc_search vs. hgnc_gene_symbol, and unichem_mapping vs. unichem_structure. Protein interaction data can also be obtained from string_interactions or intact_interactions, while literature search is split across pubmed_search, europepmc_search, and openalex_work_search. Although many database-prefixed searches are distinct, these overlapping boundaries make selection error-prone.
Naming Consistency3/5
Nearly all names use lower_snake_case and most follow a source-prefix pattern, but the action suffix is not standardized: search, lookup, query, annotate, fetch, and get are used inconsistently, and some names like pdb_structure_summary or protein_tissue_expression have no clear action. The pattern is readable but not predictable enough to support high-confidence selection.
Tool Count2/5
73 tools is far beyond the practical agent context size for reliable selection, even for a broad bioinformatics utility. Many tools could be consolidated, such as merging the BioGRID, UniChem, and HGNC search/detail pairs. The count overwhelms rather than clearly earning each tool's place.
Completeness4/5
The set covers an unusually broad range of life-science domains, including genes, proteins, variants, literature, structures, pathways, interactions, compounds, model organisms, and multi-omic data repositories. Minor gaps remain, such as no direct retrieval of full expression matrices or raw sequence files from search results, but the search-and-annotate surface is generally adequate.
Average 3.7/5 across 73 of 73 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 135 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys a read-only query/inspect operation, but it does not state what happens when assembly is empty versus set, whether list_tracks changes the response, or any external API characteristics, limits, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it repeats the same content in English and Chinese, including the list/inspect functionality and the 'for genomics research' purpose. Later sentences do not add enough new information to justify the duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema description coverage, the definition leaves important mode-selection and parameter semantics implicit. The presence of an output schema helps with return values, but the agent still lacks guidance on when to set list_tracks, how assembly selection behaves, and how this tool compares to related assembly/genome tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives an example assembly value (hg38/GRCh38) and mentions gene annotation tracks, but it never explains the list_tracks boolean parameter or the default behavior when assembly is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names UCSC Genome Browser as the resource and clearly states two modes: listing available genome assemblies or inspecting one assembly and its gene annotation tracks. This is specific enough to distinguish the tool from generic genome/assembly siblings like genome_assembly_search or ensembl_gene_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool over alternatives. The phrase 'for genomics research' is too generic and does not help an agent choose between this and the many other genomics-related sibling tools. No when-not-to-use conditions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose what the tool returns (title, resolution, method, organism, deposition date, chain sequence), which is useful. However, it does not describe error behavior, input validation, rate limits, or explicitly confirm read-only semantics beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, but it repeats nearly the same content in English and Chinese across multiple clauses. The field list and intended use case each appear twice, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers both parameters at a basic level. An agent could likely call it correctly, but the lack of usage guidance, input format specifics, and behavioral details leaves moderate gaps 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.
Parameters3/5
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 explain pdb_id as a PDB identifier and hints at chain_id through 'specified chain sequence' / '指定链序列', but it does not clarify format constraints or what 'default chain' means. The schema provides the default but not the underlying semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Get protein structure summary from PDB') and enumerates the returned fields: title, resolution, method, organism, deposition date, and chain sequence. It is clear and unambiguous, but it does not explicitly distinguish itself from sibling tools like alphafold_structure or emdb_structure_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a domain context ('for structural biology and drug design') but provides no guidance on when to choose this tool over alternatives. There are no exclusions, no mention of when another PDB-related or structure tool would be more appropriate, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the input and output types, but does not disclose data source updates, error behavior, rate limits, or other operational characteristics. The bilingual text adds no behavioral detail beyond what is already stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact, but the English and Chinese sentences are near-duplicates, adding length without new information. The front-loaded English sentence is clear, but the repetition could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and single required parameter, the description is adequate for basic use, but it lacks richer context such as the meaning of domain types, example accessions, or how results integrate with other protein-focused tools. Some gaps remain for an agent navigating a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 specify the parameter format (UniProt accession) and the output semantics (domain name, type, position). With only one parameter, this is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (query) and resource (protein structural domains from InterPro), and specifies the input (UniProt accession) and output (domain name/type/location). It does not explicitly differentiate from closely related protein tools, but the InterPro domain focus is distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for functional region analysis but provides no explicit when-to-use or when-not-to-use guidance. It does not reference alternatives like uniprot_annotate or protein_tissue_expression, nor mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds genuinely useful scope context — the GRCh38 assembly and the intended purpose of confirming official IDs/coordinates. It does not, however, reveal behavior on edge cases such as unknown symbols, ambiguous matches, or case sensitivity of the symbol.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The leading English sentence is appropriately short and front-loaded with the core action, but the two Chinese sentences repeat the same field list (Ensembl ID, chromosome location, biotype, description) verbatim. The second Chinese sentence adds only the purpose phrase, so roughly one sentence is redundant and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter symbol lookup with an output schema present, the description adequately covers the core operation and return fields. However, the `species` parameter is unexplained, there is no usage guidance relative to siblings, and the absence of annotations leaves the safety profile unstated. The gaps are real but bounded given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarifies that `symbol` is the gene symbol used as the lookup key, but it says nothing about `species`, whose default of 'homo_sapiens' appears in the schema alone — leaving an agent to guess whether other species are accepted or how to specify them. One of two parameters is effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation — 'Look up gene by symbol in Ensembl' — and enumerates the returned fields (Ensembl ID, chromosome location, biotype, description, GRCh38), so an agent knows exactly what the tool does. It does not explicitly contrast itself with sibling lookups such as ensembl_homologs or hgnc_gene_symbol, leaving differentiation implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese phrase '用于确认官方 ID 与坐标（GRCh38）' ('for confirming official ID and coordinates (GRCh38)') implies a use case: validating gene identifiers and genomic coordinates. However, it never states when to prefer this tool over siblings (e.g., ensembl_homologs, gene_full_profile, hgnc_gene_symbol) or when not to use it, so guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It mentions the Enrichr engine and that it returns significant enrichment items, giving some insight into expected behavior. But it omits details like whether it requires network access, rate limits, or if the operation is read-only. Since the description says 'analysis,' it implies non-mutating, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, and the English and Chinese portions repeat the same information. This redundancy means not every sentence earns its place. The main purpose is front-loaded, but the repeated content makes it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which covers return values), the description fails to explain the parameters' meanings, especially 'library' and 'max_terms.' Given that annotations are absent and schema coverage is nil for parameter descriptions, the definition is incomplete for an agent to confidently construct calls with non-default values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'genes' implicitly as 'gene list' and hints at 'library' via GO/KEGG/Reactome, but it does not clarify the 'library' parameter's role or the 'max_terms' parameter at all. The defaults are only in the schema. This is a significant gap for a tool with three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs gene ontology and pathway enrichment analysis using the Enrichr engine, and lists what it returns (significant enrichment terms with p-values and overlapping genes). However, it does not explicitly distinguish itself from sibling tools like kegg_pathway_search, reactome_pathway_search, or gene_go_annotation, all of which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'For functional interpretation of omics / single-cell DEGs,' which tells the agent when this tool is appropriate. It does not, however, mention alternatives or conditions when NOT to use this tool, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does convey that the tool returns only an accession list for browsing, which implies a read-only, summary-level operation. It does not mention ordering, pagination, or potential absence of results, but for a simple list tool these omissions are moderate rather than severe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats every core English clause in Chinese, so the same information is presented twice without adding anything. It front-loads the main action but uses roughly twice as many words as necessary, and the key output detail 'MTBLS accession list' is mixed into duplicated phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter listing tool, the description identifies the data source, the type of identifiers returned, and the intended browsing purpose. An output schema exists, so return-structure details are covered outside the description. The main gaps are the lack of explicit sibling differentiation and limit semantics, but these are not crippling for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single `limit` parameter with zero description coverage, and the tool description does not mention it at all. The parameter name and default of 8 provide some meaning, but because schema coverage is low the description should have compensated by explaining how `limit` controls the returned list. It does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List latest EBI Metabolights metabolomics studies' and specifies the output as an 'MTBLS accession list.' The word 'latest' differentiates it from more detail-oriented metabolomics tools, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for browsing metabolomics data' gives an implicit use context: this is a lightweight browsing/list tool for recent studies. However, it provides no explicit guidance about when to use it versus metabolomics_study or other study-detail alternatives, and no 'when not to use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose the return shape (GO annotations list with GO ID, aspect, qualifier, evidence), which is useful. However, it omits behavior around limits, aspect filtering, missing IDs, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The bilingual second sentence adds the concrete example and output detail, though it partially restates the first sentence. Overall it is efficient and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a usable calling example and output summary, and an output schema exists to cover return details. However, it leaves parameter semantics for limit and aspect undocumented and lacks guidance relative to closely related tools, making it minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies gene_product_id with an example. The limit and aspect parameters are not explained at all, leaving the agent to infer their meaning from names and defaults alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get GO annotations for a gene product'), provides a concrete input example (UniProtKB:P04637/TP53), and lists returned fields. It is clear and informative, though it does not explicitly distinguish itself from sibling tools like go_term_lookup or gene_enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for functional understanding and enrichment analysis, which gives some context. However, it does not state when to prefer this tool over related siblings, nor does it provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose the core behavior: downloading FASTA sequences and supporting accession/gene symbol/keyword queries, with selectable databases. However, it omits details such as result count limits, rate limits, or what happens for ambiguous queries across the different database options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key action, but it repeats nearly every statement in both English and Chinese, adding redundant text without additional information. This bilingual duplication makes it less concise than it should be for an AI agent consuming the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, but the tool is otherwise under-specified. The description does not explain max_ids behavior, rettype semantics, or provide when-to-use guidance relative to sibling tools. An agent would still need to infer or probe several invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 partially explains 'query' (supports accession, gene symbol, keyword) and 'db' (nucleotide/gene/protein), but it does not explain 'max_ids' or 'rettype'. An agent cannot fully understand the effect of changing these parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download'), the resource ('nucleotide/protein sequences (FASTA) from NCBI'), and the supported query types. It is distinct enough from siblings like pubmed_search or blast_search because it uniquely identifies NCBI sequence retrieval with FASTA output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual purpose ('for getting reference sequences for downstream analysis') and mentions database options, but it does not explicitly state when to use this tool versus alternatives like ENA sequence search or BLAST. There are no exclusion criteria or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently states the returned fields and the PubMed query syntax behavior, but does not disclose sorting behavior, result limits, or error/rate-limit traits. This is adequate but incomplete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes a useful, concrete query example. The Chinese translation largely duplicates the English content, adding redundancy, but the overall structure remains readable and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value details are not required from the description. The core term behavior and use cases are covered, but the missing semantics for 'sort_by' and 'max_results' leave the agent with incomplete guidance for optional parameters. The defaults make a basic call feasible, yet the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It gives meaningful syntax guidance for the only required parameter 'term' (e.g., 'BRCA1 AND breast cancer[Title]'), but says nothing about 'sort_by' or 'max_results' beyond what the schema's titles/defaults imply. Optional parameters are effectively left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a clearly identified resource ('PubMed biomedical literature'), and explicitly lists the returned fields (title/authors/journal/year/PMID/DOI). It does not explicitly contrast with sibling tools like europepmc_search, though naming PubMed provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is provided through explicit use cases (literature review, grant proposals, evidence-based search) and a query syntax example. However, there is no guidance on when not to use this tool or how it compares to sibling search tools like europepmc_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the tool returns UPI IDs, cross-references, and organism counts, and that it covers all public protein sequences. However, it does not mention query syntax behavior, pagination, rate limits, or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the essential English statement. The Chinese portion mostly repeats the same information, adding some redundancy, but overall the description remains compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details do not need to be in the description. For a simple two-parameter search tool, the core behavior is covered, but the missing relationship to uniparc_by_id leaves a modest completeness gap for an agent choosing between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds meaning to 'query' by indicating searches can be by species, gene, or protein number, which is helpful. The 'max_results' parameter is not described, though its purpose is inferable from its name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search'), the resource ('EBI UniParc protein sequence archive'), and the output types (UPI IDs, cross-references, organism counts). It is unambiguous about what the tool does, though it does not explicitly differentiate itself from the sibling uniparc_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as uniparc_by_id or other search tools. The description implies a broad use case—searching UniParc—but provides no context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully states that the output includes experimental evidence and publication references, setting expectations beyond just 'interactions'. It does not mention pagination, rate limits, error behavior, or the effect of search_type, but these are minor for a straightforward 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. It front-loads the core action and scope, then gives useful input and output expectations, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema is present, so return values do not need explanation, but the description omits search_type behavior and gives no guidance for choosing among close sibling tools. A minimal call can still be constructed from the required search_name guidance, so it is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing schema documentation. It explains search_name reasonably well with gene examples like BRCA1 and TP53, but it never mentions search_type or what values it accepts. One of the two parameters remains effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and names a specific resource ('protein interaction data from BioGRID database'), and it clarifies the expected output. However, it does not distinguish this tool from the closely named sibling biogrid_gene_interactions, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from BioGRID database' gives clear contextual context and implies this tool is for BioGRID interaction queries. It does not explicitly state when to prefer this tool over alternatives like string_interactions or intact_interactions, nor does it provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does disclose the data source, input type, and output contents (tissue-specific expression, subcellular localization, classification, disease associations). However, it does not mention limitations such as human-only data coverage or behavior for invalid/missing Ensembl IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening English sentence is clear and front-loaded, but the Chinese portion largely duplicates the same information. The bilingual repetition adds length without adding much new substance, making it adequate but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and an output schema already exists. The description provides the identifier format, data source, and what the result contains, which is enough for an agent to invoke it correctly. Remaining gaps, such as error behavior, are minor for this type of lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name with 0% description coverage, so the description must compensate. It does so by specifying that the parameter is an Ensembl gene ID and giving a concrete example (ENSG00000141510), which is sufficient for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Human Protein Atlas tissue expression profiles by Ensembl gene ID, with a specific verb and resource. It does not explicitly distinguish itself from similar-looking siblings such as expression_atlas_gene or gene_full_profile, so it stops 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example Ensembl ID and states the query type, but it provides no guidance on when to choose this tool over alternatives. There is no mention of exclusions, prerequisites, or comparison with sibling tools like expression_atlas_gene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does describe the lookup-by-name behavior and the returned bioactivity fields, but it does not disclose edge cases such as ambiguous name matching, unknown names, pagination, or how include_targets affects the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core query statement appears first, followed by return details and use-case context. The bilingual repetition adds some redundancy, but the overall length remains appropriate and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with an output schema, the description covers the primary purpose and key return values. However, it is incomplete regarding the include_targets parameter and does not clarify whether name matching is exact or partial, or what happens when no matching compound is found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'name' parameter via '按名称返回', and the output list implies target-related data, but it never explicitly explains the 'include_targets' boolean or what happens when it is set to false. One of the two parameters remains under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Query drug/compound bioactivity') and a specific resource ('ChEMBL, EBI'), and enumerates the returned fields such as ChEMBL ID, SMILES, molecular formula, clinical phase, targets, and IC50/Ki. It clearly identifies the tool's function, but it does not explicitly distinguish it from sibling tools like compound_info or chebi_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'for medicinal chemistry & target research' and '用于药物化学与靶点调研'. This tells an agent when the tool is appropriate, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does disclose that this is a query/lookup operation against PubChem and enumerates the returned identifiers and properties. However, it does not explain the effect of include_synonyms, possible API limitations, latency, or what happens for invalid or ambiguous compound names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action and source. The bilingual repetition adds some redundancy, but both sentences earn their place by also adding use-case context; it is not bloated relative to the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with an output schema, the description gives the essential purpose, source, and intended use. However, it lacks parameter-level guidance for include_synonyms, does not mention how this tool differs from chembl_drug_search or unichem_mapping, and does not describe behavior on missing/ambiguous compounds, making it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarifies that 'name' refers to a compound/drug name and lists output fields, but it never explains the include_synonyms boolean parameter or how passing it changes the response. This leaves a required parameter reasonably clear but the optional parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('compound/drug basic info (PubChem)') and lists concrete fields such as 分子式, 分子量, 规范 SMILES, IUPAC 名, InChIKey and CID. This makes the tool's purpose clear, but it does not explicitly differentiate it from the similar sibling chembl_drug_search beyond naming PubChem as the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intended-use context: 'for medicinal chemistry and docking prep' and '用于药物化学、分子对接前的化合物确认'. It does not provide explicit exclusions or alternatives, but the stated use cases are enough to indicate when an agent should reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral weight. It does reveal that the tool is a recommender/planner rather than an executor: output includes 'recommended tool, expected results, insights,' and it advertises token savings. It stops short of disclosing limitations, accepted data formats, or whether any external queries are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very compact: one purpose sentence plus labeled input/output lists. No redundant content; key information is front-loaded. Minor markdown-like labels are structurally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter router with an output schema, the core contract is present: input semantics, optional goal, and output categories. But in a 70-tool ecosystem, the description is thin on selection context and examples, so an agent might misuse it for direct analysis rather than planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description maps user_input to a 'data string' and analysis_goal to an 'optional analysis goal.' This adds moderate meaning beyond generic property titles, but it gives no format, example, length, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear verb-object pair: 'intelligently analyze biological data' and 'recommend the best analysis plan.' The output list (data type identification, recommended tool, expected results, insights) distinguishes it as an advisor/router from data-access siblings, though it never names a sibling or explicit exclusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when a user provides a biological data string and optionally a goal, and the agent wants to save tokens by getting a recommended plan. However, it does not state when not to use it, nor does it compare it to dedicated analysis tools or get_analysis_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It does reveal the read-only query nature and adds genuinely useful interpretive context (higher combined score = more reliable). However, it is silent on result limits, confidence thresholds, whether predicted vs. experimental interactions are included, and behavior for unknown or invalid proteins.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at roughly four short clauses but is bilingual with visible repetition: the query statement and the use case appear twice ('for protein functional network analysis' / '用于蛋白功能网络分析'). The Chinese half contributes non-redundant detail (input cardinality, score interpretation), so waste is limited, but an agent must parse both languages to obtain the complete picture.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 2-parameter tool with an output schema (which covers return structure), the description captures the core query behavior, input cardinality, and result interpretation. However, the species parameter being entirely undocumented is a material gap for a multi-species database like STRING, and the absence of annotations leaves operational behavior (limits, failure modes) undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds real meaning for the proteins parameter ('给定一个或多个蛋白' — one or more proteins) and explains the output scoring, but it never addresses the species parameter (default 9606, without stating it is a taxonomy ID or that 9606 is human) or the accepted identifier format (UniProt vs. gene symbols). These are both needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Query'), a precise resource ('protein interaction network from STRING-db'), and the input-output contract (one or more proteins → interaction relationships with reliability scores). Naming STRING-db distinguishes it from interaction siblings like intact_interactions and biogrid_interactions, and the score-semantics note clarifies it is a scored network query, not a sequence or literature search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context ('for protein functional network analysis' / '用于蛋白功能网络分析') and scopes the tool to STRING-db data, but it never states when not to use it or names alternatives. With multiple protein-interaction resources among the siblings (intact_interactions, biogrid_interactions, biogrid_gene_interactions), an agent receives no guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure and does state that the output is a list of maching compounds including ChEBI ID, name, and definition. It does not cover result limits, pagination, or whether matching is exac/fuzzy, which are relevant but not critical for a simple search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action, but the English and Chinese sentences are largely redundant. The Chinese version adds only the examples and a generic purpose, so some words are not earning their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema, the description covers the input semantics and the shape of the result (list, ID, name, definition). It lacks alternative-tool routing and search-behavior caveats, but it is still reasonably complete for this simplicity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'name' parameter with no description (0% coverage). The description compensates by defining it as a compound name or keyword and giving concrete examples (ATP/glucose), making it clear what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation ('Search ChEBI compounds') and the expected result (matching list with ID, name, definition). It is clear but does not explicitly distinguish itself from sibling tools like chebi_compound, which may also relate to ChEBI data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: query when you have a compound name or keyword, and the Chinese phrase '用于化合物查询' reinforces a lookup intent. However, it gives no when-not guidance or alternatives (e.g., use chebi_compound for known ChEBI ID lookups), so usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the basic behavior—keyword search yielding pathway IDs and names—but does not mention result limits, match behavior, language handling, or error cases, which limits transparency for a schema-less description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, and the bilingual repetition is not excessive. It conveys the essential purpose in two compact sentences, though the duplicated content in English and Chinese takes up space without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema, the description is mostly adequate for invocation. However, it omits guidance on when not to use the tool, behavior on no results, and any constraints on keyword format, leaving some contextual gaps for an agent selecting among many sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the bare 'keyword' property. It adds meaningful semantics by giving example keywords ('breast cancer', 'apoptosis') and clarifying that the keyword is used to find target pathway IDs, which helps an agent format valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches KEGG pathways by keyword and returns pathway IDs and names, with concrete examples. It is specific enough to identify the tool's function, though it does not explicitly contrast with sibling tools like reactome_pathway_search or kegg_pathway_genes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese phrase '用于找到目标通路编号' gives a general usage context: use this tool to discover a KEGG pathway ID. However, it does not explicitly state when to prefer this tool over alternative pathway searches or provide exclusions, leaving the selection reasoning mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It does disclose what the tool returns (title/year/citations/authors/venue) and implies a read-only keyword search, but it does not describe sorting, pagination, result-count behavior, or coverage limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear action, examples, return fields, and purpose in two short sentences. The bilingual duplication adds length but is useful for a multilingual user base and does not introduce unnecessary noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema, the description provides enough to call it: query examples, returned fields, and purpose. The main gaps are lack of sibling-selection guidance and no explicit mention of max_results behavior, but these are not critical for a basic search invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the input schema only provides property titles. The description enriches the query parameter with concrete examples ('CRISPR gene editing', 'organ-on-chip'), but max_results is only inferable from its name and default value, not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Search OpenAlex scholarly works' and lists the returned fields (title/year/citations/authors/venue). It is specific enough to distinguish itself from many sibling tools, though it does not explicitly contrast with other literature-search siblings like pubmed_search or europepmc_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: input topics or keywords, examples, and a stated purpose of literature review and citation analysis. However, it does not mention when to choose this tool over the many alternative literature/database search siblings, nor does it state any exclusions or conditions where another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does state what is returned (protein names, glycosites, modifications), implying a read-only lookup. It does not disclose behavior on invalid accessions, coverage limits, or whether only curated entries are returned, which would add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the English purpose, and is short overall. However, the Chinese sentences largely repeat the same information, so not every sentence adds new content; a single bilingual summary or key details only would be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with an output schema present, the description covers the required input, expected output fields, and intended research use. It could mention limitations or relationship to glycan_lookup, but the basics for correct invocation are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by naming the parameter's semantic type ('按 UniProt 编号') and giving a concrete example ('如 P04637'). It still lacks explicit format/validation details, but for a single accession parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Look up'), the resource ('protein glycosylation and glycan sites'), and the expected output ('protein names/glycosites/glycan modifications'). It does not explicitly differentiate itself from overlapping siblings such as glycan_lookup or protein_domains, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use context: query by UniProt accession (e.g. P04637) for glycoprotein research. However, it does not say when not to use it or name alternatives like glycan_lookup, leaving routing partially to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior, and it does state that the tool returns a list of matching genes with ID, symbol, and name. However, it does not disclose limitations such as matching semantics, result limits, pagination, or whether results are restricted only to C. elegans beyond the explicit species mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core statement is short and front-loaded, but the description repeats nearly the same content in English and Chinese. The Chinese sentence does add detail about input types and output fields, yet some of that information is duplicated, making the entry less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema, the description is reasonably complete: it identifies the organism, the query semantics, and the output content. It does not explain how to choose this tool over closely related siblings, but that is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name 'term' with no description, so the description must compensate. It does so by explaining that the term can be a gene name, function, or symbol, giving the agent meaningful guidance on what to pass. It stops short of specifying format details like case sensitivity or wildcard support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: searching C. elegans genes by keyword. It also adds useful detail about supported query types and returned fields (gene ID, symbol, name). However, it does not explicitly distinguish itself from sibling lookup tools like wormbase_gene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: keyword-driven gene discovery using a gene name, function, or symbol. There is no explicit guidance on when not to use this tool or which alternative to choose, such as wormbase_gene for exact gene records or other species-specific search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It clarifies that it matches published datasets and covers organoid/tumor/immune atlases, but it does not mention limitations, rate limits, or side effects. For a read-only search tool this is acceptable, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats the same information in English and Chinese, making it redundant. It is front-loaded with the main action, but the bilingual duplication and trailing phrases could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description does not explain 'max_results' or explicitly state usage boundaries relative to other data search tools. It does provide helpful examples of dataset types (organoids, tumor, immune), which adds context, but it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It gives semantic context for 'query' (disease/tissue/keywords), but says nothing about 'max_results'. Thus only one of the two parameters gets meaningful explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (CELLxGENE single-cell transcriptome datasets) and the action (search), and it specifies matching by disease/tissue/keywords. This clearly distinguishes it from siblings like geo_dataset_search and sra_search, which target different repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is for finding single-cell data (用于单细胞研究找数据) and published datasets, giving clear context for when to use it. However, it does not explicitly name alternatives or exclusions, so it does not fully meet the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose that the tool queries NCBI E-utilities and returns clinical significance categories, which is valuable. However, it does not mention important operational details such as rate limits, whether results are limited by max_results, or the exact output format, leaving some behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly short and front-loaded, but it repeats the same meaning in English and Chinese, creating redundancy. The bilingual content may serve multilingual users but adds token overhead for an AI agent without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query tool with an output schema, the description covers the essential context: what is being queried, what input is expected, what output is returned, and the intended clinical interpretation use case. The main gap is the lack of detail on max_results and potential result-count limits, but the overall context is sufficient for correct usage in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explain the main 'query' parameter as accepting a gene name or variant, and 'max_results' is self-explanatory with a default in the schema. However, max_results semantics are not described in the text, and the description does not fully clarify query syntax or accepted variant formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: querying ClinVar clinical variants via NCBI E-utilities and returning clinical significance classifications. It specifies the resource, the action, and the key output. It does not explicitly contrast itself with sibling tools like dbsnp_search or variant_annotate, but the focus on ClinVar and clinical interpretation makes it reasonably distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context: 'for clinical variant interpretation' / '用于变异临床解读'. It also states the input type (gene name or variant), which helps an agent decide when to call it. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does describe the output shape (matching experiments with conditions, species, data availability) and implies a safe read-only keyword search. It does not mention result limits, pagination, or behavior when no matches are found. There is also a minor inconsistency between the English output mention ('data availability') and the Chinese output mention ('实验类型与样本数').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose first, then the input/output contract, then repeats the same information in Chinese. The bilingual repetition adds minor redundancy but is not bloated. Each section earns its place for a multilingual tool interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter keyword search tool, the description is largely complete: it tells the agent what to input, what to expect as output, and gives example terms. The presence of an output schema reduces the need to document return values in detail. Missing context is limited to behavior like result limits or sorting, which is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'term' parameter (0% coverage), so the description must compensate. It does so by explaining that the term is a free-text keyword and supplying concrete examples ('cancer', 'tissue', 'disease', 'TP53'), which is genuinely useful for an agent deciding what to pass. It does not define exact syntax, but for a simple keyword parameter this is reasonably sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Search Expression Atlas experiments by keyword') and identifies the resource ('Expression Atlas experiments'). It distinguishes itself from likely sibling tools by focusing on 'experiments' rather than genes, though it does not explicitly name the alternative expression_atlas_gene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear examples of appropriate search terms (cancer, tissue, disease, TP53) and indicates the tool is for data discovery. However, it does not explicitly state when to choose this tool over siblings like expression_atlas_gene, and there are no exclusion criteria or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 return fields and query semantics (disease/tissue/experiment type with examples), which helps an agent anticipate output. It does not mention rate limits, result ordering, or that it only searches metadata, but the read-only search nature is clearly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English portion is front-loaded and immediately states the tool's purpose, followed by a concise Chinese translation. The inclusion of examples and return fields earns its place, though the bilingual repetition adds moderate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema, the description covers the resource, query usage, and return contents. It lacks guidance on when to use this over related expression/sequence tools and does not clarify the behavior of max_results in terms of truncation or default limits, leaving minor but relevant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 meaningfully explains the 'query' parameter by listing supported dimensions (disease/tissue/experiment type) and giving examples. The 'max_results' parameter is not described, though its name and default value make its purpose inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search NCBI GEO gene expression datasets.' It also names the returned fields (GSE accession, title, platform, sample count, summary), which distinguishes it from literature, sequence, and other sibling tools without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '用于表达谱研究找数据' implies it is meant for finding expression profiling data, giving some usage context. However, it does not explicitly specify when to prefer this tool over alternatives like expression_atlas_experiment or sra_search, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose the read-like nature (“获取”) and the output shape (template analysis workflow and tool list), which is useful. It does not mention limitations, behavior on unsupported scenario values, or how the template is generated, so the disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the main purpose front-loaded. The structured “输入/输出” breakdown adds clarity without repetition or fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter, an output schema exists, and the description covers the main purpose, input, and output nature. The main missing piece is a definitive list of accepted scenario values, but the examples and output schema mitigate this gap for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string parameter “scenario” with 0% description coverage, so the description must compensate. It gives examples of valid scenario types (gene research, drug discovery, disease analysis), giving the agent a general sense of valid input. It does not provide exact machine-readable keys or behavior for arbitrary values, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: “获取常见分析场景的模板方案” (obtain template solutions for common analysis scenarios). It defines the output as a templated workflow and tool list, which clearly differentiates it from the sibling search/lookup tools even without naming one explicitly. It does not explicitly contrast with a sibling, keeping it 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The “输入：场景类型(基因研究/药物发现/疾病分析等)” line implies when to use the tool: when the agent is faced with a common analysis scenario such as gene research or drug discovery. However, it does not explicitly state when not to use it, nor does it name alternative tools or describe a decision process between this and other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the search behavior and the fields returned, which is helpful. It does not mention details like matching semantics, species filtering behavior, result limiting, or error conditions, but for a read-only search tool this is an acceptable baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The bilingual repetition adds a little redundancy, but the sentence with examples and return fields is information-dense and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema, the description covers the core purpose, query examples, and return fields. It is incomplete regarding parameter nuances such as species identification, result count behavior, and how this tool compares to related pathway searches like kegg_pathway_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 provide strong semantics for the query parameter by specifying it accepts pathway names or biological processes and gives examples. However, the species and max_results parameters are not explained beyond their schema titles and default values, leaving a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Reactome biological pathways and names the returned fields (stId/name/species/summation). It is specific about the resource and the operation, but it does not explicitly differentiate this tool from similar pathway tools such as kegg_pathway_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: users should input a pathway name or biological process, with concrete examples like apoptosis, glycolysis, and DNA repair. It explains that the tool is intended for signal transduction and metabolic pathway research. However, it does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden; it does disclose the input type, the organism (rat), and the output list structure. It does not disclose result limits, matching semantics (fuzzy/partial/case-insensitive), or behavior when no genes match, so transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core behavior, but the English sentence and the Chinese sentence largely repeat one another. The bilingual duplication is a minor structural inefficiency rather than a significant clarity problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema, the description covers what the tool searches, what the input should be, and what fields are returned. It is complete enough to call correctly, though mentioning the relationship to rgd_gene_symbol would further round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'term' as a required string; the description adds genuine meaning by specifying that the term may be a gene name, function, or symbol. For a single-parameter tool this compensates for the 0% schema description coverage, though it omits an explicit example or formatting hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search rat genes by keyword'), a clear resource, and the returned fields (gene symbol, name, RGD ID). It does not explicitly contrast with the closely related sibling rgd_gene_symbol, so it stops 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '用于基因发现' ('for gene discovery') gives a clear context for when the tool is useful, and 'search by keyword' implies broad term-based discovery. It provides no explicit exclusions or guidance about the sibling rgd_gene_symbol, so the agent must infer the recommended call path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does state that the tool returns a list of databases and identifiers registered in UniChem, which is useful. However, it does not mention input format expectations, error behavior, rate limits, or explicitly confirm it is read-only beyond the verb 'look up'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-lows the key operation in English, then the Chinese sentence adds return-value detail and purpose. The bilingual repetition is slightly redundant but not bloated; each sentence contributes either the operation or the output/purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool, the description gives the operation, the input key type, the output type (source/ID list), and a purpose. An output schema exists, so return-value details do not need to be fully restated. It still lacks explicit differentiation from the sibling UniChem tool, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'inchikey' as a string with no description, so the description's clarification that the parameter is an InChI Key and the query is by that key adds meaningful semantic value. It could go further with format or example, but it sufficiently compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('look up') and resource ('compound cross-references via UniChem'), and specifies the input key. However, it does not explicitly distinguish this from the sibling tool 'unichem_mapping', which likely overlaps in the UniChem identifier-mapping space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese phrase '用于结构与标识符验证' gives an implied use case, suggesting this is for structure and identifier validation, but no explicit when-to-use, when-not-to-use, or alternative tool guidance is provided. It relies on the user to infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral transparency burden. It does disclose the read-only nature ('Query'), the supported identifier types, and the annotation fields returned. It does not disclose result-count behavior, error handling, ambiguity of gene-name queries, or any UniProt API limitations, but the core behavior is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and resource. The English and Chinese versions mirror each other, which adds some redundancy, but the overall length is still appropriate and the essential information appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple lookup tool with an output schema, the essentials are present: what is queried, which query forms are supported, and which annotation fields come back. It is incomplete in that `max_results` behavior is not addressed and no guidance is given on disambiguating gene-name queries, but this is a minor gap for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 meaningfully explains the `query` parameter by saying accession or gene-name search is supported and gives an accession example (P04637). The `max_results` parameter is not described, though its name, type, and default make its purpose reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Query'), a specific resource ('UniProt protein annotations'), and enumerates the annotation fields returned (protein name, gene, organism, length, function, Gene Ontology). It also states supported query forms (accession or gene name), which differentiates it from generic protein or sequence tools like uniparc_search or protein_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use context: 'for protein function interpretation' / '用于蛋白功能解读', which implies when an agent should reach for this tool. However, it names no alternatives and gives no exclusions or conditions for when another UniProt-related or annotation tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the data source (Ensembl Compara) and the return fields, which gives a basic sense of behavior. However, it does not mention any rate limits, authentication requirements, error handling, or whether the operation is read-only (although that's implied). This is adequate but not rich, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and the key action is front-loaded. However, it redundantly repeats the same information in both English and Chinese, which adds no value for an AI agent and could be seen as unnecessary verbosity. Still, it's compact and sets the scope early, so a 4 is fair.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value details are covered by that. However, the description omits any explanation of the parameters, which is critical given the schema has no descriptions. It also does not differentiate itself from sibling tools. For a simple query tool it's mostly sufficient, but the missing parameter guidance and lack of when-not-to-use leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions for the three parameters (symbol, species, target_species), and the description does not compensate. It mentions returning species and homolog IDs, but never explains that 'symbol' is the query gene, 'species' is the source organism, or 'target_species' is the comparison set. Given 0% schema coverage, the description must clarify parameter semantics and fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query homologous genes (orthologs/paralogs)') and the specific resource ('Ensembl Compara'), and mentions the returned data (species, homolog ID, sequence identity). This unambiguously distinguishes it from other gene-related tools like ensembl_gene_lookup, which focus on gene details rather than homologs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'for evolutionary analysis and model organisms.' It does not explicitly state when NOT to use it or name alternative tools, but the intended use case is implicit from the phrasing. Since it lacks explicit exclusions or sibling comparisons, a score of 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It transparently says the public REST API no longer exposes numeric per-gene values and that results are experiments matching the gene's description/species. This is a substantive, honest limitation disclosure that goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English portion is concise and front-loaded, but the Chinese section repeats much of the same information without adding new guidance. Phrases like '此处诚实返回相关实验' are more rhetorical than operational, adding noise for an agent deciding when to call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and there are only two simple parameters, the description is largely complete for invocation: it identifies inputs, the matching behavior, and the key limitation. It could be stronger with an explicit pointer to expression_atlas_experiment or matching semantics, but nothing essential for a basic call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the two undocumented parameters. It adds real meaning to gene_id by specifying that it accepts a gene ID or symbol with concrete examples TP53 and ENSG00000141510. It also notes species is optional, though it does not describe acceptable species values beyond relying on the schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Find Expression Atlas experiments relevant to a gene.' It clearly names gene identifiers and species as inputs, and differentiates this from numeric expression retrieval by explaining the REST limitation. It does not explicitly name or contrast the sibling expression_atlas_experiment tool, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: it is for finding experiments where a gene's expression can be viewed, and it notes that numeric per-gene expression values are not returned. However, it does not name any alternative tool for numeric values or experiment metadata, nor does it say when not to use this tool beyond the numeric limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool matches an English keyword and returns GO term IDs, names, and aspects, but it does not state whether matching covers names, synonyms, or definitions, how case sensitivity works, or how the limit parameter affects results. 'Search' implies read-only behavior but never states it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core verb+resource front-loaded. The bilingual restatement is partially redundant, but the Chinese portion carries the only concrete examples, return-field detail, and use-case statement, so each sentence contributes information rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema (which already covers return values), the description covers what is searched, how, and the intended downstream use. The remaining gaps — limit semantics, search scope (names vs synonyms/definitions), and routing guidance relative to go_term_lookup — are minor rather than blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It adds genuine meaning for keyword by giving example values and the English-only requirement, but it never mentions limit — its meaning, range, or effect on result count — leaving one of two parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Search), resource (Gene Ontology terms), and method (by keyword), and it goes further with concrete examples (apoptosis / kinase / membrane) and the return contract (list with ID, name, and aspect). The keyword-based method functionally distinguishes it from the sibling go_term_lookup without requiring the agent to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the intended context ('used for functional annotation and enrichment analysis') and constrains input to English keywords, which implies when it is useful. However, it does not explicitly state when to use this tool versus alternatives like go_term_lookup or gene_go_annotation, and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the operation is a read-like list operation returning genes, which is the core behavior. It does not disclose potential limitations, such as whether the gene list contains symbols, Entrez IDs, or both, though the presence of an output schema mitigates this. There is no contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats the same core statement in English and Chinese: 'List genes in a KEGG pathway', 'returns the genes in the pathway', and '返回该通路下的基因' all say essentially the same thing. The example and purpose are valuable, but the redundancy bloats an otherwise simple definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter and an output schema, the description is mostly complete. It names the resource type, gives an example pathway ID, and states the purpose. It could be improved with explicit guidance about pathway ID construction, but an agent can likely invoke the tool correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented pathway_id parameter. It does so by providing the example 'hsa05224=Breast cancer', which conveys both the format (organism-prefixed KEGG ID) and an example value. It could go further by explicitly stating the required format, but the example is enough for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List genes in a KEGG pathway.' It clearly states the output as the gene list for that pathway and even gives an example pathway ID (hsa05224=Breast cancer), making the purpose unambiguous. This also distinguishes it from the sibling kegg_pathway_search, which searches for pathways rather than retrieving genes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need the genes belonging to a KEGG pathway, e.g., to understand the molecular composition of the pathway. However, it never explicitly addresses alternatives or when not to use this tool, such as preferring kegg_pathway_search when the goal is finding pathways.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It helpfully states that the operation returns compound names, definitions, chemical properties, and cross-references, and gives an example ID. However, it does not disclose error handling, exact input normalization, or whether the operation is read-only, though 'query' and 'return' imply a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English sentence is concise and front-loaded, with the Chinese sentence adding concrete return fields and use case. There is some redundancy between the two languages, but the overall size is appropriate and every key piece of information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with an output schema available, the description covers the essential information: what input to provide, an example, and what kind of data will be returned. It lacks a reference to the related search tool and edge-case behavior, but the core invocation context is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only 'chebi_id' with no description (0% coverage). The description compensates by explaining that this should be a ChEBI ID and gives the example 'CHEBI:15377 ATP'. This is helpful, though it does not specify whether bare numeric IDs are also accepted or whether the 'ATP' text is part of the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Query ChEBI compound by ChEBI ID' and elaborates with what is returned: compound name, definition, chemical properties, and cross-references. It is specific and understandable, but it does not explicitly contrast itself with the sibling tool chebi_search, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: when you have a ChEBI ID, supply it as input, and the tool returns compound information for chemical biology research. It does not explicitly discuss when not to use it or mention alternatives such as chebi_search, but the intended use case is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses that this is a search operation and lists the returned fields, but says nothing about result limits, ordering, error behavior, or pagination. For a simple search tool this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, but the entire English content is redundantly repeated in Chinese. That duplication adds no information for an agent, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, one required, and an output schema, the description covers the overall purpose, query patterns, and return fields. It is missing a brief note on max_results and does not differentiate from overlapping sibling tools, but an agent could still invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explain the query parameter well with concrete syntax examples, but it does not describe max_results at all. Since max_results is a simple integer with a default, this is a modest gap; partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Search NCBI dbSNP genetic variants.' It further specifies query dimensions (gene/position/rs number), gives concrete examples, and enumerates return fields (rsID, chromosome, position, alleles, clinical significance), making it easily distinguishable from sibling tools like clinvar_query or variant_annotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by showing exact query syntax for gene and rs-number searches. It implies when to use this tool, but does not explicitly name alternatives or exclusion conditions, so it stops short of the strongest routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It does state the operation (search), the resource (Europe PMC), and the return fields (title/journal/authors/DOI/open-access status), which is meaningful. However, it omits any detail about rate limits, required auth, pagination, or query syntax, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core function in the first sentence. The Chinese repetition adds the usage context ('suitable for literature review') not present in the English, so each sentence adds some value. Minor redundancy between the two languages keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple two-parameter search tool with an output schema, so the description does not need to explain returns. It covers what, where, and a use case, and provides a distinction from PubMed. Missing are explicit exclusions (e.g., when not to use it) and search syntax hints, but for the tool's complexity the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level detail. query and max_results are self-explanatory by name, so the agent can guess their meaning, but the description does not elabore on query syntax, supported fields, or how max_results behaves. With zero schema descriptions, the tool description should compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (full-text literature search) and a specific resource (Europe PMC/EBI). It explicitly differentiates from PubMed by noting it includes open-access full text, which is the key distinction among siblings. This makes the tool's identity and scope instantly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual guidance: it explains that Europe PMC search includes OA full text beyond PubMed and marks it as suitable for literature reviews. It does not explicitly state when-not-to-use or name the alternative pubmed_search, but the contrast with PubMed is enough to imply the selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It communicates that the operation is a read-only search, defines the result fields, and gives query format hints. However, it does not discuss result limits, pagination, failure modes, or any NCBI-specific constraints such as API rate limits or availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and stays reasonably short, but it repeats nearly all content in English and Chinese. This bilingual duplication adds no new semantic information for an LLM agent and slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema present, the description covers scope, query syntax, and expected return fields. The only notable gap is lack of mention of max_results behavior, but the tool is otherwise adequately contextualized for initial use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of param meaning. It substantially explains the 'query' parameter with example values and allowed content (species or assembly name), but it says nothing about 'max_results', leaving that parameter to be inferred from its default value and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search NCBI Assembly genome assemblies', and scopes it to bacteria/virus/eukaryote. It also lists the returned fields (accession/name/organism/type/status) and gives example queries, making it unambiguous and distinguishable from sibling search tools like taxonomy_lookup or sra_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the input type (species or assembly name), provides concrete NCBI query syntax examples, and indicates the intended research use case. It does not explicitly name alternatives or when-not-to-use scenarios, but the context is clear enough for an agent to select it for assembly-level searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does indicate a read-style operation, identifies the NCBI E-utilities source, and enumerates output fields. However, it does not disclose behavior for invalid IDs, missing records, rate limits, or response error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by input and output details. The Chinese sentence is redundant with the English text aside from naming NCBI E-utilities, but the overall length is still appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter ID lookup with an output schema available, the description provides enough operational context: lookup mode, input format, output fields, and the underlying data source. It could add guidance for not-found cases, but this is a minor gap for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines sample_id as a string with no description, so 0% schema coverage means the description must compensate. It does so by providing concrete example formats (SAMN00000001, SAMEA123456), which meaningfully clarifies the expected parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Get'), a specific resource ('biological sample metadata'), and the key qualifier ('by sample ID'). Listing the output fields also distinguishes it from broader search tools like biosample_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by sample ID' implies this should be used when an accession is already available, but there is no explicit guidance on when to choose this over biosample_search or other lookup alternatives. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the term can be a gene name, function, or symbol and that a matching list is returned. It does not disclose matching semantics (fuzzy vs. exact), result limits, pagination, or no-match behavior, but it also does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the English statement, and every clause adds some content — the Chinese sentence repeats the English but contributes the return-field detail and purpose. The bilingual duplication is mildly redundant rather than harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-paramter keyword-search tool with an output schema documenting the return shape, the description adequately covers input semantics, scope, and intended use. It lacks an explicit sibling distinction from flybase_gene and any limit/error expectations, but nothing critical is missing for correct basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sole 'term' paramter, and it does: specifying that term accepts gene names, functions, or symbols adds real meaning beyond the bare 'string' type. It stops short of giving format/case examples, but the paramter is otherwise well clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+method ('Search Drosophila genes by keyword') and adds return details (gene ID, symbol, name) and the discovery use case. This clearly distinguishes it from ID-lookup and other-organism siblings like flybase_gene, wormbase_search, and hgnc_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '用于基因发现' (for gene discovery) implies a discovery-oriented use case, and 'Drosophila' implicitly routes the agent away from wormbase/rgd/hgnc searches. However, there is no explicit when-to-use vs. flybase_gene (likely ID-based lookup), no exclusions, and no statement of what not to use it for, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that the tool queries multiple databases concurrently ('一次并发返回') and frames itself as cross-validation, which is useful. However, it does not mention partial-failure behavior, rate limits, network dependence, or data freshness across the four external sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and immediately lists the concrete output components. The bilingual repetition of the same idea is slightly redundant but does not introduce noise or obscure meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an aggregator with two parameters and an output schema, the description covers the core purpose, the output sources, and the intended scenario. The main gap is the under-documented `species` parameter and lack of caveats about external-database failure behavior, but an agent can still select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarify that `symbol` means a gene symbol, but it leaves `species` undocumented except for the schema default `homo_sapiens`. No guidance is given on valid species values or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs combined multi-database gene analysis, enumerates the exact data sources (Ensembl, UniProt, STRING, PubMed), and says it returns several output categories concurrently. This distinguishes it from single-source siblings like ensembl_gene_lookup and uniprot_annotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly targets 'project kickoff and functional overview' / '开题调研、蛋白功能概述', which gives an agent a clear when-to-use context. It does not explicitly mention when not to use it or recommend alternative single-database tools for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the core read-only nature ('look up') and the key returned fields. However, it does not mention what happens with invalid/unknown accessions, whether the accession format is validated, or any source/version details. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the English purpose and is not overly long, but it repeats the same information in Chinese, which adds redundancy for an AI agent. The structure is a single run-on sentence rather than cleanly separated clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description covers purpose, input format, and returned fields. It omits error behavior, identifier normalization, and relationship to similar glycan-related tools, leaving some gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a parameter name with 0% description coverage. The description compensates by explaining that the parameter is a GlyTouCan accession and gives a concrete example ('G00051MO'). It does not provide a full pattern or edge-case guidance, but the example makes the parameter usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('look up'), a specific resource ('glycan structure by GlyTouCan accession'), and enumerates the returned data (composition, mass, monosaccharide count, sequence info). This clearly distinguishes it from sibling lookup tools like lipid_lookup or protein_glycosylation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended context explicit: look up a glycan by its GlyTouCan accession, for glycomics research. It does not explicitly discuss when not to use this tool or mention alternative tools, but the input requirement and purpose are clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently states that this is a lookup operation and enumerates what will be returned, including the GO aspect categories. It does not discuss invalid ID handling, but for a simple read-only lookup the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by a useful expanded explanation with input example and output details. Every sentence contributes value, and the bilingual phrasing is not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description is nearly complete: it gives the input format, the purpose, and the expected return fields. It could be slightly stronger by explicitly distinguishing from GO search tools, but this is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It explicitly identifies the parameter as a GO ID and provides a concrete example (GO:0006915), which adds meaningful format guidance beyond the bare schema field name 'go_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (look up) and resource (Gene Ontology term by GO ID), and even enumerates the returned fields (name, aspect, definition, synonyms). It does not explicitly differentiate from sibling tools like go_term_search, but the 'by GO ID' scoping makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case: when you have a GO ID and want details to understand gene function annotations. It does not explicitly say when to use this tool versus alternatives such as go_term_search or gene_go_annotation, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does state what input forms are accepted and what output fields to expect (approved symbols, names, aliases). However, it does not disclose edge-case behavior such as case sensitivity, partial matching, result limits, or empty-result handling, which are useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The action is front-loaded, and the input/output contract follows immediately. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema available, this description is largely complete: it covers purpose, parameter semantics, and high-level output. It could additionally point to when not to use it or mention alternatives, but that gap is relatively minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a property named 'query' with zero description coverage, so the description must compensate. It does so by explicitly defining the acceptable values: a gene symbol such as BRCA1 or a gene name keyword. That is sufficient for the single parameter, though it doesn't describe constraints like case sensitivity or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Search') and resource ('human gene nomenclature'), and clarifies that the query can be a gene symbol (BRCA1) or a name keyword. It clearly distinguishes the human/HGNC scope from many organism-specific sibling tools, though it does not explicitly name an alternative, so it falls just 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditions for use: when you have a human gene symbol or a gene name keyword. It also states the input format directly. It does not mention exclusions or direct alternatives such as hgnc_gene_symbol, but the context is clear enough that an agent can tell when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior, and it discloses the lookup action and the returned fields (name/formula/SMILES/InChIKey/DB cross-refs). It does not mention behaviors such as exact-match requirement, case sensitivity, availability, rate limits, or error handling, but for a simple read lookup the core behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the key action in the first phrase. The bilingual repetition adds length but is purposeful for the apparent Chinese-speaking user base; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with an output schema, the description covers what the tool does, what to provide, and what comes back (name/formula/SMILES/InChIKey/DB cross-refs). Minor omissions, such as exact matching behavior or acceptable LM ID formats beyond two examples, keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's lm_id parameter has no description (0% coverage), so the description is the only source of semantic meaning. It provides the identifier type (LM ID), concrete examples (LMFA01030001 arachidonic acid, LMGP01010001 phosphatidylcholine), and states the expected input pattern, which adequately compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('Look up LIPID MAPS lipid structure'), the resource (LIPID MAPS), and the key identifier (LM ID), and enumerates returned fields (name/formula/SMILES/InChIKey/DB cross-refs). This is specific enough to distinguish it from sibling compound/metabolite tools like compound_info or chebi_compound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied through the examples and '用于脂质组学研究' (for lipidomics research), but no explicit guidance says when to prefer this tool over alternative compound/glycan/metabolite lookups. It gives clear context but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Search' implies a read-only operation, and the description does disclose return fields. However, it does not mention any limitations, pagination behavior, result-count semantics, or potential API quirks, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably short and front-loaded with the core search statement. It includes helpful examples and return information, but the English and Chinese portions are largely duplicative, which adds some redundancy without adding new information for bilingual readers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema, the description covers the target database, query semantics, and typical use case. The main missing pieces are clearer treatment of max_results behavior and any guidance on when to prefer sibling tools, but the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds meaningful semantics for the required 'query' parameter by explaining it takes a host or habitat and providing examples. However, 'max_results' is not explained in the description, though its schema title provides limited self-evident meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Search') on a defined resource ('EBI MGnify microbiome metagenomics studies') and lists concrete outputs (study accession, name, samples, bioproject). It is distinct from the broader sibling search tools because it names the exact database and domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete input guidance—host or habitat examples such as 'gut microbiome', 'human', 'soil'—and states it is intended for microbiome research. It does not explicitly compare against sibling tools like bioproject_search or sra_search, but the domain and input examples are clear enough for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the search behavior and the returned fields, but it does not disclose potential limitations such as result limits, case sensitivity, or metadata-only search scope. This is adequate but has room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the English summary, followed by a slightly redundant but detail-rich Chinese explanation. It earns its place by adding examples and output specifics, though the bilingual repetition is a minor inefficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema present, the description is largely complete: it gives the keyword purpose, examples, and expected result details. Missing pagination or sorting behavior is minor given the low complexity and the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 keyword parameter and providing concrete examples ('cancer/human/tissue'). This gives the agent practical guidance on acceptable inputs, though it stops short of defining formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Search), the resource (PRIDE proteomics projects), and the method (by keyword). It also describes the output contents (title, species, data access links), making its function immediately obvious and distinct from generic search tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that the tool is for keyword-based data discovery in PRIDE, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, such as using pride_project for specific project lookups, leaving some routing to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the input format (gene symbol with Brca1/Tp53 examples) and the return contents (gene name, symbol, chromosome location, functional annotation, aliases), which establishes this as a read-style lookup. However, it does not address edge-case behavior: exact vs. partial matching, case sensitivity, what happens for non-rat symbols, or error handling for invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the English sentence states the core operation first, and the Chinese segment adds input format and return-field detail. There is mild redundancy from bilingual repetition, but each sentence earns its place — no filler, no schema echo.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 an output schema present, the description covers the essentials: purpose, input format with examples, and return contents. The output schema handles precise return typing. Minor gaps remain (failure modes, explicit tool-selection guidance against rgd_search/hgnc_gene_symbol), but nothing an agent needs to make a correct call is fundamentally missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the symbol property has only a title, no description. The tool description compensates well by naming the parameter's meaning ('输入大鼠基因符号') and giving two concrete real-world examples (Brca1/Tp53). This is meaningful added value beyond the bare schema. It does not specify format constraints, but for a single gene-symbol string the examples largely carry the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement — 'Get rat gene by gene symbol' — that clearly identifies the operation and its input. The organism qualifier ('rat') distinguishes it from sibling lookups like hgnc_gene_symbol (human), flybase_gene, and wormbase_gene, so an agent can recognize it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the tool is '用于大鼠遗传学研究' (for rat genetics research) and specifies the input type (rat gene symbol). However, it provides no explicit when/when-not guidance or alternatives, even though closely related siblings exist (rgd_search for broader RGD queries, hgnc_gene_symbol for human genes). The context is clear but the exclusion logic is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It states that the tool returns corresponding database IDs for an InChIKey and includes the list of databases, but it does not disclose edge-case behavior such as no-match results, multiple mappings per database, or whether the input must be a canonical InChIKey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English lead sentence states the core function concisely, and the Chinese sentence adds specific database examples and the intended use case. The bilingual duplication is slightly redundant but does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with an output schema available, the description covers the input, the databases involved, and the purpose. It does not need to enumerate return fields, but a brief note about not-found or multi-mapping behavior would have made it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 effectively identifies the single parameter as a 'standardized chemical identifier InChIKey' and explains its role as the query input. It could add exact format or normalization details, but for one simple string parameter the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and clearly identifies the resource: compound identifier mapping across databases by InChIKey. It also names concrete target databases (ChEMBL/PubChem/DrugBank/ChEBI), which differentiates it from sibling compound-related tools such as unichem_structure or chembl_drug_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case ('for cross-database compound query and integration'), so an agent can infer when to use it. However, it does not explicitly state when not to use it or how it compares to alternatives like unichem_structure or compound_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose the output type ('list of matching samples with metadata') and the backend ('NCBI E-utilities'), but it omits practical details like result limits, pagination, rate limits, or how exact term matching behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action and resource. The Chinese sentence repeats the English meaning, creating slight redundancy, but it adds the NCBI E-utilities context at negligible length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema provided, the description is adequately complete: it gives the query syntax, expected result shape, and backend context. It lacks pagination/limit details, but the low complexity and existing output schema make that a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the single 'term' parameter. It does so effectively by giving concrete syntax examples: 'human[Organism]', 'cancer', and 'tissue:lung', which clarify supported search patterns far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Search biological samples by keywords') and gives concrete example terms. It clearly distinguishes from sibling 'biosample_by_id' by emphasizing keyword-based search rather than identifier lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The input examples imply the intended usage, but the description never explicitly says when to use this tool over alternatives or when not to use it. No exclusions or routing to 'biosample_by_id' for accession-based lookups is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states output granularity ('returns top hits') and the exact fields returned, which is meaningful beyond what the tool name alone conveys. It does not mention latency, rate limits, or program/database selection details, but it does not mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation and uses compact one-line case descriptions. English and Chinese sections repeat the same content, which is somewhat redundant for an agent, but the overall size is small and every distinct piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, the description does not fully specify acceptable program/database combinations, especially using 'blastp' for protein sequences instead of the default 'blastn'. Output schema covers the return structure, but the query-parameter domain is underspecified for a general agent. The required parameter, defaults, and common use cases are present, so it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It clarifies that 'sequence' can be DNA or protein and that results are top hits whose count is governed by max_hits. However, program/database values and how to choose blastp vs blastn for protein queries are left implicit, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'NCBI BLAST homology search for DNA or protein sequences.' It also lists return fields ('top hits: accession/species/E-value/identity/description'), which distinguishes it from sibling retrieval/search tools such as ncbi_fetch_sequence. Clear, specific, and unique among the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'For sequence identification, homolog discovery, primer validation' line gives explicit use cases, so an agent can decide when this tool fits. It does not name exclusions or siblings to prefer in other cases, but the context is clear and actionable for this type of search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 query syntax pattern ([Strategy] AND term), the class of resource (raw sequencing reads), and the exact fields returned. As a read-only search it needs no side-effect warning, though rate limits and API behavior are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and compact, but the Chinese sentence repeats nearly the same content, adding redundancy without new information. The query example is useful, but the duplication costs it a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A two-parameter search with an output schema needs only modest guidance. The description provides query semantics, a realistic example, the intended use case, and the returned fields; only explicit routing to alternatives and max_results behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 query parameter well (gene/species/strategy with an example), but max_results is not addressed beyond its schema default and title. This is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search'), an exact resource ('NCBI SRA sequence read archive'), and a differentiator ('raw sequencing data') plus the returned accession fields. This cleanly separates it from siblings like pubmed_search or geo_dataset_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear use context: finding raw sequencing data by gene/species/strategy, with a concrete query example. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It clearly presents this as a read-only lookup operation, explicitly stating the return payload and the 200M+ protein coverage. It does not mention error cases or rate limits, but for a simple query tool the disclosed behavior is adequate and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main verb and resource, and communicates essential information in a compact bilingual format. The Chinese/English repetition adds mild redundancy, but it does not obscure the meaning or bloat the description excessively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter query tool with an output schema available, so the description need not detail every return field. It gives the access point, output categories, and data scope, which is largely complete. The main absence is explicit guidance relative to sibling structure tools, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only names the parameter 'Uniprot Acc' with no description, so the description compensates by explaining that the parameter is a UniProt accession. It lacks an explicit format or example, but the required identifier type is clear and sufficient for a knowledgeable agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Query'), the resource ('AlphaFold DB'), and the expected result fields (pLDDT confidence, sequence length, PDB download link). This is sufficiently distinct from sibling tools like pdb_structure_summary because it explicitly names AlphaFold DB and the returned confidence metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case: given a UniProt accession, retrieve AlphaFold-predicted structure data. However, it does not explicitly state when to prefer this tool over related alternatives such as pdb_structure_summary, nor does it mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states the output type (interaction partners with experimental evidence and detection methods) but does not mention read-only nature explicitly, potential for large result sets, rate limits, or error behavior. The 'Get' verb implies a read operation, but more transparency would be ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core purpose, input requirements, and output summary with no filler. The key statement is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers purpose, inputs, and output sufficiently. It does not address edge cases or alternative sibling tools, but the essential information needed to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully compensates by explaining both parameters: gene_symbol with an example (TP53) and organism with a default/example (9606=human). This goes beyond the raw schema and clarifies parameter meaning and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and a specific resource ('protein interactions for a specific gene symbol from BioGRID'), which is more specific than a generic interaction query. It does not explicitly differentiate from the sibling tool 'biogrid_interactions', 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: provide a gene symbol, optionally an organism ID, and receive interaction partners. It does not mention alternatives or when not to use this tool, but the input/output guidance is explicit enough to select it for gene-centric BioGRID queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It adequately discloses that this is a search operation returning project accession, title, description, and organism, and the 'AND' example illustrates boolean query behavior. It omits pagination or rate-limit details, but for a read-only search tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, examples, and return fields appear early. The bilingual repetition is slightly redundant, but the Chinese portion adds the purpose phrase about linking to sequencing projects, so the extra length is not wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema, the description covers the resource, query syntax, output fields, and intended purpose. Missing explicit alternative guidance and max_results semantics are somewhat minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explain the query parameter well with examples and accepted identifier forms, but it never mentions max_results or how the limit behaves. The max_results meaning is only inferable from its title and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search NCBI BioProject biological projects', naming a specific verb and resource, and then clarifies the search inputs (topic/accession) and outputs (accession/title/description/organism). This makes the tool easy to distinguish from siblings like pubmed_search or ncbi_fetch_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete usage context: searching by topic such as 'gut microbiome AND human' or by BioProject ID such as PRJNA123456, and mentions the goal of associating large-scale sequencing projects with datasets. However, it does not explicitly name sibling tools like sra_search or biosample_search or explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the tool makes '真实 HTTP 请求' (real HTTP requests) to each endpoint, reports actual reachable/unreachable status and codes, and makes '不做乐观假设' (no optimistic assumptions). This is meaningful behavioral context beyond the name and schema. It does not cover timeout side effects or rate limits, but these are less critical for a health-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place. The English sentence is front-loaded with the core purpose, and the Chinese sentence adds essential behavioral detail (real HTTP requests, status codes, no optimistic assumptions). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with an output schema, the description covers what the tool does, how it behaves, and how the results should be used. The output schema handles return-value structure. The only notable gap is the undocumented timeout parameter semantics, which is already penalized under parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'timeout' parameter at all. An agent must infer from the parameter name and default that it controls request timeout. The description provides no units, scope, or behavior advice, so it fails to compensate for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check which bioinformatics databases are currently reachable.' This clearly differentiates the tool from the many search/query siblings, which all fetch domain-specific data. The additional Chinese text reinforces the scope by describing endpoint connectivity checks across database endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: '返回结果用于确认当前环境下哪些数据库可用' (results are used to confirm which databases are available in the current environment). This implies using the tool before or while deciding which database-specific tools to invoke. It does not explicitly name alternatives or exclusions, but the health-check purpose is distinct enough to route usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description frames the operation as a 'Get' lookup and explicitly states that it returns an rsID list, making the read-only nature and output shape clear. It does not describe default limit effects or no-result behavior, but those are minor for this simple 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main operation, while the Chinese expansion adds a concrete example, the output format, and an intended research use. The two sentences have some bilingual overlap but each contributes useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with an output schema, this description covers the tool's purpose, required input format, expected output type, and use case. It does not mention sibling alternatives or explain the limit parameter in depth, but the tool is simple enough that the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 `gene` parameter with a concrete example (TP53) but provides no added meaning for `limit`, which is only represented by its title and default value in the schema. The partial compensation is adequate but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get GWAS variants associated with a gene,' then specifies the input as a gene symbol and the output as a list of associated variant rsIDs. This gene-centric framing distinguishes it from sibling tools like gwas_variant_associations, which appears variant-centric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese portion gives explicit usage context: query by gene symbol such as TP53 and use for gene-variant-disease association research. It does not explicitly mention when not to use the tool or name alternatives, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the data source (Ensembl Plants), the read-only nature ('Look up'), and the returned output fields. However, it does not address exact-match behavior, ambiguity, error handling, or access/rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English description is compact, front-loaded, and well-structured with clear input/output labeling. The trailing Chinese sentence repeats most of the English content, adding mild redundancy for an English-reading agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with an output schema available, the description covers purpose, source, input examples, and output fields. Missing exact species identifier formats and explicit sibling routing are minor gaps but do not make the tool unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, but the description compensates with concrete examples: gene symbol formats like AT1G01010/AGL1 and species values like arabidopsis/rice/maize/wheat/soybean. It loses a point because these common-name species examples may not match the exact schema default `arabidopsis_thaliana`, creating potential value-format ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Look up plant gene information via Ensembl Plants.' The plant+Ensembl Plants scope clearly distinguishes it from generic Ensembl lookup siblings, and the example species and gene symbols reinforce the tool's domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying that this is for plant gene lookup and lists valid species and symbol examples. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Input: none' and describes the output as 'common plant species names mapped to Ensembl species IDs', making the operation's scope and result format clear. While it does not discuss potential errors or data freshness, for a parameterless list tool this is substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English description is compact and front-loaded with the core purpose in the first sentence. However, the Chinese sentence largely duplicates the output description ('列出支持的植物物种及其对应 Ensembl 物种名'), introducing minor redundancy. It remains appropriately sized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and a dedicated output schema, the description covers the essential aspects: purpose, input, and output format. It could be slightly more explicit about how the species list integrates with plant_gene_lookup, but the provided context is sufficient for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema properties are empty, so the baseline is 4. The description reinforces this by stating 'Input: none', which removes any ambiguity about whether arguments are expected. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'List supported plant species for BioMCP plant gene lookup' uses a specific verb (List) and resource (supported plant species), and clearly states the tool's role within the BioMCP plant gene workflow. It distinguishes itself from sibling tools like plant_gene_lookup by focusing on the enumeration of supported species rather than gene queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for BioMCP plant gene lookup') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion conditions. An agent must infer that this list should be consulted before querying plant_gene_lookup, which is a plausible but not explicitly stated workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly indicates that this is a read-only search, shows the query syntax with [Title] and [Organism] field tags, and states the returned fields (accession/title/organism/length). It does not mention rate limits or pagination, but for a simple search tool the behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the core purpose, then gives practical query examples in both English and Chinese. The Chinese portion repeats the English information, but it also adds the usage context ('分子克隆与载体设计'), so the length is justified. It avoids unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool, this description is largely complete: it specifies the data source, query construction, use case, and return fields. The output schema handles return structure, so the main gap is the lack of any guidance on `max_results` or result limits, which is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate. It does a good job explaining the `query` parameter by providing concrete NCBI query examples. However, the `max_results` parameter is not described or mentioned anywhere, leaving its semantics to be inferred from the schema default of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a clear resource ('NCBI plasmid sequences') and further specifies the operability domains, such as plasmid name or host organism. Examples of query syntax make the tool's purpose unmistakable. It is readily distinguished from sibling tools like pubmed_search or ncbi_fetch_sequence because of the plasmid-specific scope and result fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for searching NCBI plasmid sequences by name or host, for molecular cloning and vector design. It does not explicitly state when not to use alternatives, but the purpose and query examples give enough situational clarity to an agent deciding between this and other biomedical search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly frames this as a read-only lookup and enumerates the returned fields, which is sufficient for a simple retrieval tool. It stops short of discussing ID validation or error behavior, but those are minor given the tool's straightforward nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The bilingual expansion adds useful detail rather than pure repetition, though the closing phrase about intended research use is somewhat non-essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description covers the key details: data source, required input format, and expected return fields. An agent has enough information to invoke the tool correctly for a Drosophila gene ID lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter description and 0% coverage, so the description must compensate. It does so by naming the parameter's role and providing a concrete example ID (FBgn0000015), giving the agent enough context to format the input correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get Drosophila gene by FlyBase ID') and names the resource. The description also lists the returned data fields and gives an example ID, making the tool's purpose unmistakable and distinct from search-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to provide a FlyBase ID implies the tool is for use when the user already has a stable gene identifier. It does not explicitly mention alternatives like flybase_search or say when not to use this tool, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal what the tool returns (associated traits, p-values, risk allele frequency, effect sizes), but it does not mention behavior for invalid or missing variants, evolutionary/population scope, or limitations of the source data. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The bilingual repetition adds some length but the Chinese portion also contributes meaning by adding the output fields and use cases. No filler or off-topic content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter lookup tool with an output schema available. The description covers purpose, lookup key, example input, output content, and intended applications. For the tool's complexity, this is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 'rsid' with no property description, and schema coverage is 0%. The description compensates by explaining that the input is a dbSNP number and provides a concrete example ('rs73229090'), which is sufficient for a single well-known identifier type. It could additionally specify strict format rules, but the example makes the intended input clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a concrete resource ('GWAS associations for a variant'), and a precise lookup key ('by rsID'). It also gives an example rsID and names the returned data fields, making the tool's role unmistakable and distinguishing it from related tools like gwas_gene_variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when this tool is relevant: querying variant-level GWAS results for genetic association interpretation and Mendelian randomization studies. It does not explicitly name alternative tools for other use cases such as gene-level GWAS, so it falls just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the input format and the broad output categories (aliases, chromosomal location, previous symbols), which gives basic transparency, but it does not mention what happens for invalid or deprecated symbols, case sensitivity, or whether only current approved symbols are accepted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. It front-loads the core purpose, then cleanly separates input requirements and output contents, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 an output schema available, the description is largely complete: it states the entity type, the required input format, and the nature of the returned data. It could be slightly stronger by pointing to hgnc_search for cases where the user only has a partial symbol or gene name, but this is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a field named 'symbol' with 0% description coverage, so the description must compensate. It does so effectively by giving explicit examples ('BRCA1, TP53') and clarifying that the symbol must be an HGNC approved symbol, adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a specific resource ('detailed human gene information'), and the exact key ('HGNC approved symbol'). It also distinguishes itself from sibling tools like hgnc_search by emphasizing exact-symbol lookup rather than searching, and from rgd_gene_symbol by being human-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool: when you already have an HGNC approved gene symbol such as BRCA1 or TP53. It does not explicitly mention alternatives or exclusion criteria, but the input requirement is specific enough that an agent can infer this is for exact approved-symbol lookup rather than fuzzy or cross-species searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that this is a search operation and specifies the returned content types: interaction partners, detection method, and evidence. It also gives concrete identifier examples. It does not mention pagination or rate limits, but for a read-only search tool the core behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action and resource, and includes a bilingual restatement that also adds the validation use case. Every part contributes useful information, and no filler or redundant schema details appear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema present, the description covers the query semantics, output contents, and an intended use scenario. It does not explicitly explain max_results or differentiate from other interaction-database siblings, but these are minor gaps given the output schema and simple nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarify the query parameter with examples ('TP53', 'P04637') and maps it to gene or protein identifiers. However, max_results is not described at all; only its name and default value in the schema hint at its meaning. Thus the description partially compensates but leaves one parameter semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search EBI IntAct experimentally-validated molecular interactions.' It clearly states what is returned—interacting partners, detection method, and evidence—and the qualifier 'experimentally-validated' helps distinguish it from predicted-interaction tools like string_interactions. The bilingual text reinforces the same precise purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: '用于验证蛋白互作网络' (for validating protein interaction networks), and specifies acceptable inputs such as gene symbols or UniProt IDs. It does not explicitly state when to prefer this over sibling tools like string_interactions or biogrid_interactions, but the context is clear enough for basic tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state the output fields and the query mechanism, which is reasonable transparency for a simple retrieval tool; however, it does not mention behavior for invalid IDs, missing studies, or any potential rate limits. This is a moderate disclosure, not a severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The essential information is front-loaded: the source, the resource type, the identifier format, and the returned fields appear early. The bilingual repetition adds some redundancy, but it remains compact and does not obscure the key facts, so it is still reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity retrieval tool with one parameter and an output schema, the description covers the query mechanism, the source database, and the main returned content. It does not discuss edge cases like invalid accessions, but the presence of an output schema and the simple nature of the tool make this a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a raw 'study_id' string with no description, so the description's explanation that it should be an MTBLS accession number (e.g., MTBLS1) is essential and highly valuable. It fully compensates for the 0% schema description coverage by defining the parameter format and giving a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving EBI Metabolights metabolomics study details by MTBLS accession number, and explicitly lists the returned fields (title, description, technology, design, factors). This makes its purpose distinct from sibling tools like metabolomics_latest, which are not about retrieving a specific study by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool is used by supplying an MTBLS number such as MTBLS1, which is clear usage guidance for the intended scenario. It does not explicitly name alternative tools or state when not to use it, but the accession-based lookup instruction provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states what the tool returns (project title, abstract, species, experimental type, data files) and its intended purpose. It does not cover failure modes or response formatting details, but for a simple ID-based fetch 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core operation and resource. The bilingual repetition adds a slight redundancy, but it remains only two sentences and contains no filler or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only fetch-by-ID tool with an output schema available, the description supplies the essential information: the input format, the resource, and the expected return categories. The only notable gap is not explicitly mentioning the pride_search sibling as the appropriate tool when the ID is unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions, so schema description coverage is 0%. The description compensates fully by specifying the parameter format ('PXD project number') and giving a concrete example ('PXD000001'), which tells an agent exactly how to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Get'), a specific resource ('PRIDE proteomics project'), and a precise lookup key ('by ID'). It also enumerates the returned content (title, abstract, species, experiment type, data files), making the tool's purpose unambiguous. The 'by ID' phrasing also distinguishes it from the sibling pride_search tool without needing an explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you already have a PXD project ID and need project details. However, it does not explicitly say when not to use it or point users to pride_search for query-based discovery, so the guidance is reasonably clear but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly indicates a read-only retrieval and lists the specific data returned (sequence length, sequence, cross-references), which is transparent enough for a simple lookup. It omits error behavior and data-source caveats, but these are minor for an ID-based fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The descripotion is compact and front-loaded with the most essential information. The Chinese sentence is largely a duplocate of the English sentence and adds limited new value ('all' for cross-references), creating minor redundancy without bloating the overall size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only one required parameter, the description covers the input contract and highlights the main output fields. It does not mention the prerequisite that a UPI ID must already be known or direct the user to uniparc_search for ID discovery, which would fully round out the interaction flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates by explaining the single parameter 'upi': it states the input is a UPI number and provides a concrete example (UPI0000123165). This gives an agent everything needed to format the argument correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get UniParc record details by UPI ID.' It also enumerates the return payload (sequence length, sequence, cross-references), which makes the tool's function unambiguous and distinguishable from a search-oriented sibling like uniparc_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by UPI ID' implies the tool should be used when an ID is already known, but it never states this condition explicitly. It does not reference a sibling like uniparc_search for discovering IDs, nor does it provide any when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the input formats (HGVS or rsID), the data sources (GnomAD/1000G, SIFT/PolyPhen), and the categories of returned information. It does not discuss error behavior or service dependencies, but for a straightforward read-only annotation lookup this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and remains compact. The main inefficiency is bilingual duplication: the Chinese text largely repeats the English content, and 'for variant interpretation' appears twice. Still, the structure is clear and the redundancy is not severe.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one required parameter and an output schema exists, so the description need not detail return values. It covers accepted inputs, example formats, and the intended interpretation purpose. It would be more complete with explicit guidance on when to choose this tool over related variant or annotation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it explicitly explains that the 'variant' parameter accepts HGVS notation with a concrete example (chr13:g.32911145G>A) or an rsID. This is exactly the semantic guidance an agent needs to populate the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Annotate human genetic variants (MyVariant.info)'. It clearly distinguishes itself from sibling tools like dbsnp_search or clinvar_query by naming a dedicated annotation service and listing its scope and output categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for variant interpretation' gives an implied use case, and the description explains what inputs are accepted and what results are returned. However, it does not explicitly state when to prefer this tool over alternatives such as dbsnp_search or clinvar_query, nor does it mention 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.
Behavior3/5
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 returns gene information (a behavioral trait) but does not explicitly state whether the operation is read-only or any side effects. As a 'Get' tool, this is implied, but not clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, one in English and one in Chinese. The information is front-loaded, but the repetition across languages is minor redundancy. It is still efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with an output schema, the description is complete: it states the purpose, the input format, and the type of returned data. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for gene_id. The description compensates by explaining the expected format (WormBase ID) and providing an example (WBGene00000001), adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a precise resource ('C. elegans gene'), and the method ('by WormBase ID'). It also lists the returned data types (name, symbol, chromosome location, functional annotation, sequence information), making it clearly distinct from broader search tools like wormbase_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you have a WormBase ID for a C. elegans gene. It implies the appropriate scenario but does not explicitly mention alternatives or when-not-to-use. Since the tool is specialized, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 tool's core behavior: it returns title, authors, resolution, macromolecules, and dates for a given EMDB entry. It does not cover error handling or edge cases, but for a read-only lookup these is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the English purpose. The Chinese sentence repeats the same content, which is somewhat redundant, but it reinforces the input example and intended use case without adding verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter, an existing output schema, and no nested objects, the description covers the essential invocation context: what to pass and what to expect. It could mention alternative tools or exact ID format acceptance, but it is adequate for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for emdb_id, so the description compensates by explaining the parameter is an EMDB entry number and providing a concrete example (EMD-1234). This adds the meaning that the bare schema lacks, though format details beyond the example are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Look up EBI EMDB cryo-EM structure entry'. It clearly identifies the domain (cryo-EM), the database (EMDB), and the expected output fields (title/authors/resolution/macromolecules/dates), making it distinguishable from sibling structure tools like PDB or AlphaFold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: when you need EMDB cryo-EM structure information by EMD number, explicitly including an example input (EMD-1234). It does not name alternatives or exclusions, but the context is specific enough that the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently states what the tool lists and the distinction between e2e_verified and best_effort statuses. It also mentions that tools needing extra configuration are highlighted. It does not discuss side effects, but as a zero-parameter listing tool, the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core function. The bilingual repetition adds minor length but serves accessibility and does not introduce fluff. Every sentence contributes either what the tool does or when it should be used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema provided, the description is complete: it explains the tool's purpose, the categories it reports, and the use case. There is no missing information that would prevent a agent from selecting or invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so no additional parameter explanation is needed. The baseline score for zero-parameter tools is 4, and the description adds no unnecessary parameter details, appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all BioMCP tools with their data source and verification status'. It clearly differentiates this tool from the sibling tools, all of which are domain-specific searches, by marking it as a meta-level inventory tool. The bilingual text reinforces the exact output contents (data source, verification status, extra configuration needs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: to understand the credibility of each tool and avoid over-trusting unverified endpoints. It provides clear usage context, though it does not explicitly name alternatives or exclusions. Since it is a meta-inventory tool with no obvious sibling competitor, the lack of explicit alternatives is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It clearly describes a read-only lookup behavior, names the data source, lists the returned data fields, and gives concrete input examples. It does not discuss edge cases like no matches or multiple hits, but for a simple lookup tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action and resource. The bilingual repetition adds length, but it also broadens accessibility and does not obscure the key information. Every meaningful element—purpose, input format, and output fields—is present without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, the description is complete: it defines the accepted query formats, the data source, the returned fields, and the intended purpose. An output schema exists and no nested/enum complexity is present, so nothing critical is missing for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully compensates by explaining that the 'query' parameter accepts either a species name or a NCBI taxid, and provides concrete examples (9606, human). This is exactly what an agent needs to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and a clear resource ('NCBI Taxonomy species classification'), and states the returned fields: scientific/common name, rank, and lineage. This makes it easy for an agent to distinguish this tool from the many sibling tools, none of which target NCBI taxonomy classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context: confirm the official classification of a species, and specifies accepted inputs (species name or taxid, e.g., 9606, human). It does not explicitly name alternatives or exclusion conditions, but no close taxonomic sibling exists and the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bio-mcp MCP server](https://glama.ai/mcp/servers/qgeng1465/bio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/qgeng1465/bio-mcp)

Score Badge

Copy to your README.md:

[![bio-mcp MCP server](https://glama.ai/mcp/servers/qgeng1465/bio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/qgeng1465/bio-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qgeng1465/bio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server