plant-genomics-mcp

Server Quality Checklist

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

Latest release: v1.21.0
Disambiguation4/5
Most tools have distinct purposes, but there are a few areas of overlap: bar_gene_summary and tair_locus_info are explicitly aliases, and multiple homology tools (gramene_homologs, orthodb_orthologs, consensus_homologs, find_homologs_synth) could confuse an agent. However, descriptions help differentiate them.
Naming Consistency5/5
All tools use consistent snake_case naming with clear prefixes like 'batch_' and 'synthesis'. Patterns like 'locus_' for gene-level queries and 'batch_' for batch operations are predictable and aid usability.
Tool Count3/5
With 50 tools, the server feels heavy for a single MCP. While each tool serves a specific need, the count is high and could be streamlined, e.g., by merging some batch variants into parameterized single tools.
Completeness4/5
The tool surface covers a wide range of plant genomics tasks: sequence retrieval, homology, interactions, pathways, ontology, variants, literature, and synthetic outputs. Minor gaps exist (e.g., no dedicated miRNA or epigenetic data), but core workflows are well-supported.
Average 4.5/5 across 45 of 50 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 78 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive. Description adds context: it runs BLAST and resolves UniProt-shaped accessions, and handles non-UniProt subjects by returning null. No contradiction with annotations.
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, minimal waste. However, 'Synthesis: one-call equivalent of the find_homologs prompt' is jargon that may confuse.
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 output schema exists, return values are defined. Description mentions output structure. Tool complexity is moderate (3 params, 1 required). Missing parameter details lower it slightly.
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 only 33% (only 'sequence' described). Description does not explain 'top_n' or 'program' beyond defaults. With low coverage, description should compensate but 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 the tool runs BLAST then resolves UniProt accessions, returning ranked hits. It distinguishes from siblings like blast_sequence (BLAST only) and batch_gramene_homologs (batch homolog 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 tool is a 'one-call equivalent of the find_homologs prompt' but does not explicitly list when to use vs alternatives or when to avoid.
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?
Description adds specific behavioral constraint (up to 50 loci per call) beyond annotations. Annotations already declare readOnly, idempotent, and non-destructive, so minimal additional disclosure needed.
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?
Extremely concise single sentence, front-loaded with key information. Could include slightly more detail without harming conciseness.
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?
Adequate for a simple batch tool with output schema present. Minimal description but sufficient given the tool's straightforward nature and rich annotations.
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?
Description provides no parameter information. Schema coverage is only 33% (organism described), and the description does not compensate for the missing parameter semantics for loci and top_n.
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?
Explicitly states it is the batch version of atted_coexpression, with a clear limit of 50 loci per call. This distinguishes it from the single-locus sibling tool.
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?
Implies usage for batch coexpression queries with multiple loci. Does not explicitly state when not to use or mention alternatives, but the 'batch' prefix in name and description provides clear 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context beyond 'Up to 50 inputs per call,' which is already in the schema. No contradictions.
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, no filler, front-loaded with key information about batch nature and capacity.
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 the output schema exists and annotations cover safety, the description provides the essential batch limit and links to the parent tool. Could mention how results are returned or any processing specifics, but sufficient for a simple batch wrapper.
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 only 33% (organism has description). The description adds value by noting the 50-input limit, which relates to loci_or_accessions, but does not elaborate on limit or organism parameters. Baseline 3 is appropriate.
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 it's a batch version of string_interactions, specifying the resource and the batch limit (up to 50 inputs). This distinguishes it from its single-input sibling.
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 implies use when multiple inputs need processing, and the sibling list includes string_interactions as the alternative. However, it does not explicitly state when not to use or provide detailed 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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context: it resolves loci via UniProt, returns first-neighbor partners with combined STRING score plus per-channel sub-scores. This goes beyond annotations without contradicting them.
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 sentences long, each carrying distinct and valuable information: tool purpose, input handling, and output details. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, the description appropriately highlights key output features (first-neighbor partners, scores) without needing to enumerate fields. It covers input resolution, organism specification, and default settings, making it self-contained for an API 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?
All parameters are described in the input schema (100% coverage). The description adds further meaning by explaining the resolution of locus identifiers and the flexible organism specification (slug, name, taxid), which is not fully captured in the schema descriptions.
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 fetches protein-protein interaction partners from STRING-DB, specifying input types (UniProt accession or locus identifier) and default organism. It is specific and actionable, but does not explicitly contrast with sibling tools that also provide interaction data (e.g., bar_aiv_interactions, experimental_interactions), which keeps it from 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 description explains input requirements and how to specify organism, including resolution of locus IDs. However, it provides no guidance on when to use STRING-DB versus alternative interaction sources, nor any conditions under which this tool is preferred or should be avoided.
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?
Annotations already indicate read-only, idempotent, open-world, non-destructive behavior. The description adds valuable context: parallel fan-out, 50-locus limit, and the output structure per locus. No contradictions with annotations.
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 sentences with no wasted words. It front-loads the core identity ('Batch variant of get_gene_xrefs') and then details behavior concisely.
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?
Given the presence of full annotations and an output schema, the description is complete. It covers the batch nature, parallelism, limits, and output shape. No critical missing information for effective tool 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 100%, so baseline is 3. The description does not add meaning beyond the schema; it mentions the loci parameter implicitly but does not elaborate on organism. The parameter semantics are adequately covered by the input 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 clearly identifies this as a batch variant of get_gene_xrefs, describes the parallel fan-out over Ensembl Plants with a max of 50 loci, and specifies the output shape per locus. It effectively distinguishes this tool from the single-locus version.
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 implicitly suggests use for multiple loci, but lacks explicit guidance on when to use this vs alternatives (e.g., the single-locus get_gene_xrefs or other batch tools). No when-not-to-use or alternative mentions are 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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by explaining parallel execution and error handling (successes in results, errors in errors), going beyond what annotations offer.
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 sentences with no wasted words. It front-loads the purpose ('Batch variant of locus_literature') and efficiently covers parallelism, limits, and result structure.
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?
Given the tool's complexity (batch, parallel, error handling), the description covers all key aspects: it's a batch, fan-out, max 50 loci, per-locus response payload. Output schema exists, so return values are covered. No 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 100%, and the description does not add significant meaning beyond what the schema already provides. It mentions 'up to 50 loci' which is already in schema maxItems. Baseline score of 3 is appropriate.
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 it is a batch variant of locus_literature, specifies parallel per-locus searches for up to 50 loci, and describes the results structure. This distinguishes it effectively from the single-locus sibling.
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 when multiple loci are involved but does not explicitly state when to use this tool versus other batch tools like batch_locus_go_annotations or alternatives. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safe, idempotent behavior. The description adds significant behavioral context: the pipeline of resolving to UniProt, parallel fan-out, and merging scores into a consensus ranking. No annotation contradictions.
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, front-loaded with core purpose, no wasted words. Efficiently conveys all key aspects.
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 the tool's complexity (multiple data sources, output schema exists), the description covers the overall workflow and output (consensus ranking). However, it omits details about how 'top_n' and 'organism' affect the results, leaving some ambiguity.
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?
With schema description coverage at only 33% (only organism documented), the description should compensate but does not explain 'locus' or 'top_n' parameters. It only indirectly references input via 'resolves UniProt accession' and 'consensus partners ranking', leaving the parameters partially underspecified.
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 it is a 'one-call equivalent of the biological_context prompt' and enumerates the specific operations (resolve UniProt, fan out to Gramene, KEGG, STRING, ATTED-II, and add consensus ranking). This distinguishes it from sibling tools that perform individual lookups.
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 implies usage as a convenience tool for broad biological context, but does not explicitly state when to use it versus calling individual sibling tools or when not to use it. The context is clear but lacks explicit 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?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description adds behavioral context: the API caps the span and will error on oversized regions, and defaults to arabidopsis_thaliana. This goes beyond what annotations provide.
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 at about 6 sentences, with the purpose in the first sentence. It includes necessary warnings and defaults without unnecessary verbiage. However, parameter descriptions could be omitted since they are fully covered in the schema.
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 the tool has 5 parameters, a required set, and an output schema (not shown), the description covers the purpose, parameter roles, a use case, a behavioral caveat, and defaults. It does not explain the output format, but the output schema suffices. It adequately distinguishes from sibling 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 100%, so the baseline is 3. The description adds minor clarifications like '1-based inclusive' for start/end and provides an example region '1', but largely restates schema information.
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 'List features overlapping a genomic interval' which uses a specific verb and resource. It distinguishes from sibling tools by explicitly contrasting with 'per-locus lookup', and provides concrete use cases like 'what genes are in this QTL interval'.
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 explains when to use this tool ('without a per-locus lookup') and provides defaults for feature and organism. It warns about oversized region errors. However, it does not explicitly state when not to use it or list alternative tools beyond the implicit per-locus methods.
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?
The description adds value beyond annotations by detailing the returned data (effect size, minor-allele frequency, molecular effect, phenotype/study) and noting that 'association_count is the true total even when page-capped.' It also warns about OrganismNotSupported. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).
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 highly informative sentences with no wasted words. First sentence states purpose and source, second sentence details output fields and constraints. Structure is clear and front-loaded.
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 the presence of an output schema, the description does not need to explain return values. It covers the source, free nature, organism restriction, output fields, and page-capping caveat. Complete enough for the tool's 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 coverage is 100% (both parameters described). The description reinforces the organism default and restriction but does not add new details about the 'locus' parameter beyond the schema. Baseline of 3 is appropriate as description adds marginal 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 specifies a specific verb ('Fetch'), resource ('AraGWAS genome-wide association study hits'), and target ('Arabidopsis locus'). It clearly distinguishes itself from sibling tools, as none of the siblings specifically perform GWAS association retrieval for Arabidopsis.
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 the tool is 'ARABIDOPSIS-ONLY' and defaults to arabidopsis_thaliana, providing clear context for when to use and what organism to input. However, it does not explicitly mention alternatives or when not to use, though no sibling tool overlaps in function.
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?
The description adds context beyond annotations: parallel execution, 50-locus limit, organism constraint per call, and the varying result payload per organism (papers vs partners). It does not contradict annotations.
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 efficiently convey purpose, constraints, and result structure without redundancy. Every sentence adds value.
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 the batch complexity and existing output schema, the description covers parallelism, limit, organism sharing, and result structure. Minor gap: no explicit error handling beyond mentioning errors[locus], but overall sufficient.
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 coverage is 100%, so baseline is 3. The description adds that loci are identifiers with success/failure mapping in results and errors, but does not significantly extend schema-provided parameter meanings.
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 it is a batch variant of bar_aiv_interactions, outlines the parallel fan-out for up to 50 loci, and specifies the result structure per locus. It distinguishes itself from the single-locus sibling by focusing on batch processing.
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 implies usage when querying multiple loci, noting the constraint that all loci share the same organism. It distinguishes from the single-locus variant but does not explicitly compare with other batch tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it fans out in parallel with a 50-locus limit and specifies error handling (errors[locus]), providing useful context beyond annotations.
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: first sets context (batch, parallel, limit), second describes output structure. Every sentence earns its place with no superfluous 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?
Given the output schema exists, the description adequately covers batch behavior, limits, and error handling. However, comparing to siblings, it could better highlight when to prefer this batch tool over others.
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 100%, but the description adds value by explaining loci limits and stating that organism accepts slugs, scientific/common names, or NCBI taxids, aiding correct parameter usage.
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 this is a batch variant that fans out per-locus BioMart queries in parallel, and specifies the max loci and output structure, distinguishing it from the single-locus sibling.
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?
It identifies as a batch version but does not provide explicit guidance on when to use it versus other batch tools or the single-locus version, missing opportunities to guide selection among numerous siblings.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds no contradictory information and provides minimal behavioral context beyond the annotations, resulting in an adequate but not enhanced score.
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?
Extremely concise at two sentences. Front-loaded with the core action, immediately followed by essential usage details and examples. No wasted words.
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 simple parameters, full schema coverage, rich annotations, and presence of an output schema, the description is sufficiently complete. Could optionally mention pagination or result limits, but it's not necessary for basic usage.
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?
Both parameters are fully described in the schema (100% coverage). The description adds value by providing real-world examples (e.g., AT1G01010 for Arabidopsis) and explaining the organism parameter's flexibility (canonical slug, name, taxid), which goes beyond the schema's basic 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 explicitly states 'Fetch metadata for a plant locus identifier from Ensembl Plants,' with a specific verb and resource. It distinguishes from sibling tools like phytozome_lookup_locus by specifying the Ensembl Plants origin and providing locus examples.
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 usage context: defaults to arabidopsis_thaliana, lists example organisms, and explains the locus identifier format. Does not explicitly mention when not to use, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. Description adds detailed behavior: resolves via Ensembl Plants, fans out to xrefs, UniProt, Europe PMC, QuickGO in parallel, and returns a SynthesisEnvelope with per-step status and cross-source disagreement flag.
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 well-structured sentences: first summarizes purpose, second details process and output. No unnecessary words.
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?
Given the tool's complexity (synthesis of multiple lookups) and the presence of an output schema, the description adequately explains the workflow, parallel fan-out, and the nature of the returned envelope including conflict detection.
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 coverage is 100% with both parameters documented. Description does not add new meaning beyond schema, so baseline 3 applies.
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?
Clearly states it is a one-call equivalent of the analyze_locus prompt, resolves a locus, fans out to multiple sources, and returns a SynthesisEnvelope. Distinguishes itself from sibling tools that target individual sources.
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?
Implies usage as a comprehensive replacement for multiple lookups but provides no explicit when-to-use or when-not-to-use guidance compared to sibling tools like get_gene_xrefs or resolve_locus_to_uniprot.
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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: the tool is 'keyless' (no API key required) and a Global Core Biodata Resource (2023), and it replaces a previous subscription-gated stub. No contradictions with annotations.
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 concise (two sentences) and front-loaded with the main action. Every sentence adds value: first sentence states purpose and data sources, second sentence adds scope, access, and replacement context. No wasted words.
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?
Given the presence of an output schema, parameter schema with full coverage, and annotations, the description provides sufficient context about the tool's purpose, scope, and behavioral traits. It is complete for a read-only summary tool with clear domain constraints.
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 100% coverage with a clear description for the single 'locus' parameter ('Arabidopsis AGI locus, e.g. AT1G01010'). The description does not add additional parameter semantic detail beyond the schema, but schema already provides sufficient information.
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's purpose: fetching a merged summary for an Arabidopsis locus from BAR's ThaleMine and GAIA-aliases, detailing what data is returned (TAIR curator summary, Araport11 description, NCBI Gene ID, cross-DB aliases). It distinguishes from siblings by mentioning it replaces the old tair_locus_info stub and is Arabidopsis-only.
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 specifies that the tool is for Arabidopsis loci only ('Arabidopsis only') and is for the 'curator-summary use case.' It does not explicitly state when not to use it or compare with sibling tools, but provides enough context for appropriate use.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details about the return structure (per-replicate values, control samples, lat/lng, mean) and the data source (wraps a specific endpoint). No contradictions with annotations.
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 a single paragraph with the main purpose front-loaded. It is concise but includes necessary context (resource details, data elements, scope). Every sentence adds value.
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?
Given the tool has only one parameter, good annotations, and an output schema (present but not shown), the description covers purpose, scope, data source, and return structure adequately. No gaps for an agent to select or invoke 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?
Schema coverage is 100% with one parameter (locus) described as 'Arabidopsis AGI locus, e.g. AT1G01010'. The description adds context by specifying that it must be an Arabidopsis locus and provides an example, adding value beyond the 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?
Description clearly states it fetches world-map natural-variation expression data for an Arabidopsis locus from BAR/eFP, specifying the resource and what is returned (expression across ~36 ecotypes with per-replicate values, control samples, lat/lng, mean). This distinguishes it from sibling tools like bar_gene_summary or arabidopsis_natural_variation.
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 restricts usage to Arabidopsis and mentions BAR is keyless and a Global Core Biodata Resource, implying open access. However, it does not explicitly contrast with sibling tools or state when to prefer this over 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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds important behavioral constraints: batch size limit and organism support limitation, including that other organisms raise OrganismNotSupported.
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, concise and front-loaded with the purpose. Every sentence adds value: batch nature, limit, and version-specific constraint.
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 description covers essential aspects: batch behavior, limits, and organism constraint. With output schema present, return values are handled. It could mention when to prefer batch over single, but the version note adds useful 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?
Schema description coverage is 50% (organism parameter described in schema, loci not). The tool description adds meaning for both: 'Up to 50 loci per call' for loci and clarifies organism limitation beyond schema text. It provides valuable context that complements the 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 clearly states it is a batch version of kegg_pathways with a limit of 50 loci, and it specifies the organism constraint. It distinguishes itself from the single-version sibling by being a batch tool.
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: up to 50 loci per call and organism limitation (only arabidopsis_thaliana supported). It implies when to use batch vs. single but does not explicitly contrast them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, but the description adds substantial detail: resolving UniProt + FASTA, parallel execution, deduplication by normalized locus token, and the exact scoring formula with per-source identity contributions. This goes well beyond the structured hints.
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 concise, front-loaded with the core purpose, and every sentence adds meaningful detail about sources, algorithm, and scoring. No wasted words or redundant repetition of the schema.
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 complex, and the description covers the pipeline, scoring, and deduplication. The output schema handles return-value documentation. However, it does not mention the role of top_n or possible caveats when sources disagree, leaving a modest completeness gap.
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 documentation covers only the organism parameter (33% coverage). The description adds meaning for locus by explaining it is resolved to UniProt + FASTA and used in normalized locus tokens, but it does not explain top_n or clarify how many results are returned. This partial compensation leaves a clear gap.
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 purpose: 'cross-source homology consensus' combining Gramene and NCBI BLAST with a defined scoring method. It distinguishes itself from sibling tools like gramene_homologs and blast_sequence by emphasizing the synthesis/deduplication behavior.
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 strongly implies when to use this tool: when a cross-source consensus of homology calls is needed rather than a single-source result. It does not explicitly name alternatives or give 'when-not-to-use' guidance, but the synthesis framing provides clear usage 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details: how IDs are resolved (base ID resolves to newest version), and that unknown IDs raise a typed NotFoundError. No contradiction.
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?
Description is a single paragraph but efficiently conveys purpose, scope, companion tool, ID format, and error handling. Slightly dense but well-structured.
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?
Given the tool has an output schema, the description doesn't need to detail return values. It lists key data fields and covers ID format, companion tool, and error handling. Fully complete for this 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?
Schema coverage is 100% with description for matrix_id. The description adds meaning by explaining it accepts versioned (MA0570.1) or bare base IDs (MA0570, resolves to newest), which goes beyond the schema's type 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 clearly states the tool fetches a JASPAR binding profile by matrix id, listing specific data returned (PFM, TF class, etc.). It distinguishes itself from sibling tool tf_binding_motifs as the drill-down companion that returns the full matrix.
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 positions this tool as the drill-down companion to tf_binding_motifs, guiding when to use each. It also explains ID versioning (versioned vs base) and error behavior. No explicit when-not, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds substantial context: the free access, the resolution step to UniProt, the query by geneProductId, and the exact return structure (annotations[] with specific fields plus a by_aspect rollup deduped on goId). No contradictions.
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 a single, well-structured paragraph of 4-5 sentences. It front-loads the core purpose and source, then efficiently covers the resolution logic, return format, and deduplication. Every sentence adds value without 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?
Given the tool's complexity (dependency on another tool, structured return data) and the presence of an output schema (not shown), the description compensates by detailing the return fields and the rollup structure. It omits error handling or limitations, but coverage is high for a tool with many siblings.
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 coverage is 100% for the three parameters, each with a description. The description reiterates the locus resolution but does not add new semantic meaning beyond the schema. The baseline is 3, and the description does not elevate it further.
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 'Fetch Gene Ontology annotations for a plant locus from QuickGO (EBI).' It specifies the resource (QuickGO), the operation (fetch annotations), and the target (plant locus). It distinguishes from siblings like go_enrichment and locus_plant_ontology by mentioning the specific data source and the deduplication strategy.
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 notes 'Free, no API key,' indicating no authentication barrier. It also explains the dependency on resolve_locus_to_uniprot logic, linking to a sibling tool. However, it does not explicitly state when to use this tool over alternatives like go_enrichment, nor does it give negative guidance. The context is clear but lacks explicit exclusions.
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?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context about data source (Planteome), filtering by NCBI taxon, return format (annotations array and by_ontology rollup), deduplication on term_id, and coverage limitations. No contradictions.
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 well-structured with front-loaded purpose and key details. It is slightly verbose (5 sentences) but every sentence contributes value, including usage guidelines and return format. Could shorten coverage explanation but still concise.
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?
Given the output schema exists, the description explains return format (annotations[] and by_ontology rollup), covers defaults (organism, limit), and notes behavior for unsupported organisms (empty list, not error). Complete for this tool's 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 100%, so the schema itself documents all parameters adequately. The description adds minor examples (AT1G01010, Os01g0100100) and notes that organism accepts multiple forms, but does not add substantial meaning beyond the 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 clearly states the tool fetches Plant Ontology (PO), Trait Ontology (TO), and experimental-condition (PECO) annotations from Planteome for a plant locus. It distinguishes itself from the sibling tool 'locus_go_annotations' by specifying that QuickGO serves GO while Planteome serves plant-specific ontologies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives: 'Complements locus_go_annotations: QuickGO serves GO (species-agnostic), Planteome serves the plant-specific ontologies — PO (anatomy + developmental stage), TO (traits).' Also mentions coverage limitations and default organism.
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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds that the tool walks gene→enzyme→catalyzed reactions→pathways, returns found=false for non-enzymatic genes without error, caps lists but reports true totals via reaction_count/pathway_count, and details response structure (enzymes[], reactions[], pathways[]). No contradiction with annotations.
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 well-structured with front-loaded purpose, followed by walkthrough, special cases, count behavior, and supported organisms. Every sentence adds value, though it is somewhat lengthy. No redundancy.
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?
Given the presence of annotations and an output schema, the description provides all necessary information: purpose, input parameters with extra context, behavioral details (non-enzymatic handling, capped lists, true totals), supported organisms, and contrast with other resources. It is complete for an agent to select and invoke 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?
Schema coverage is 100%, but the description adds significant meaning: for 'organism', it specifies accepted formats (slug, scientific/common name, NCBI taxid) and lists the 11 supported organisms; for 'locus', it provides examples (AT3G51240, Os11g0530600). Default organism is stated. This goes beyond the schema 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 tool fetches metabolic annotations for a locus from PlantCyc, specifying the walkthrough from gene to enzyme to reactions to pathways. It explicitly distinguishes itself from KEGG and GO, and lists supported organisms and the default. The verb 'fetch' with the resource 'metabolic annotation for a locus' is 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 indicates when to use (to get metabolic-pathway view not provided by KEGG/GO) and which organisms are supported (listing 11, noting wheat is not mapped). It also explains behavior for non-enzymatic genes. However, it does not explicitly mention when not to use or directly contrast with siblings like kegg_pathways, though the differentiation is implied.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: the ATTED-II release is resolved per-organism, and unsupported organisms raise OrganismNotSupported. It also describes the output: locus, Entrez ID, and z-score ranking.
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?
Three sentences, each adding necessary information: action, return format, organism resolution, and pairing hint. No filler or repetition.
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?
Given 3 parameters (1 required) with 67% schema coverage and an output schema, the description covers the core functionality, supported organisms, error behavior, and integration with a sibling tool. It is fully adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (locus and organism documented). The description adds meaning to top_n by specifying it returns 'top_n neighbors' and clarifies the z-score meaning. This compensation warrants a 4.
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 'Fetch co-expressed gene neighbors from ATTED-II' and specifies the return format (target locus, Entrez ID, z-score). It also explicitly mentions pairing with string_interactions to identify functional partners, distinguishing it from sibling tools like string_interactions itself.
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 by listing supported organisms and noting that unsupported ones (wheat, sorghum, etc.) raise an OrganismNotSupported error. It also hints at use with string_interactions for high-confidence partners. However, it does not suggest alternative tools for unsupported organisms.
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?
Annotations already indicate readOnly, idempotent, nondestructive behavior. Description adds return format ('standard batch envelope with count + results dict + errors dict'), providing valuable behavioral details beyond annotations.
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 with no wasted words; critical information (limit, filter sharing, return envelope) is front-loaded.
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?
All essential aspects are covered: purpose, limits, filter behavior, return envelope. Tool has output schema so return details aren't needed in description.
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 covers 50% of parameters; description adds sharing behavior for homology_type and reaffirms the 50-loci limit, which is not fully captured in 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?
Clearly states it's the batch version of gramene_homologs with explicit 50-loci limit and shared homology_type filter, distinguishing it from the single-locus sibling.
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?
Implicitly guides when to use (multiple loci) by contrasting with 'batch version', but does not explicitly mention when not to use or name the alternative single tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: parallel fan-out, batch size limit of 50, and error handling per locus. This goes beyond annotations.
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 succinctly convey the tool's batch nature, parallelism, limits, and output structure. Every sentence is informative and well-placed.
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?
Given the presence of an output schema and detailed annotations, the description fully covers the tool's purpose, behavior, limits, and result format. No critical gaps remain.
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 coverage is 100% and each parameter has a schema description. The tool description adds no additional semantic information about parameters beyond what the schema already provides.
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 it is a batch variant of resolve_locus_to_uniprot, performing parallel searches for up to 50 loci. It explicitly distinguishes from the single-locus sibling by specifying batch behavior and result structure.
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 indicates it is a batch variant, implying use for multiple loci, but does not explicitly state when not to use or list alternatives among sibling batch tools. However, the context is clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, open world), the description discloses the crucial failure-isolation behavior: any single backend failure degrades only that section to 'Unavailable' while the rest still renders. It also explains the return envelope structure (result.markdown headline + sections mirror), adding real behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the essential ('Synthesis: one-shot...'); every clause earns its place by explaining scope, fan-out sources, output format, and failure behavior. No redundancy or filler.
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 complex multi-source synthesis tool, the description covers inputs (locus resolution), processing (fan-out list), outputs (Markdown + sections), and failure semantics. With a rich schema and output schema present, this is complete enough for an agent to 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 100%, so the schema already documents all three parameters. The description references 'locus' in passing but adds no additional semantic detail about top_n or organism; per the baseline, a 3 is appropriate.
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 this as a one-shot gene dossier synthesis tool with a specific verb ('tell me about this gene') and resource scope, distinct from sibling tools that query individual data sources. It enumerates the fan-out targets (Ensembl Plants, UniProt, KEGG, STRING, Europe PMC, QuickGO) and the headline output, making the purpose unambiguous.
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 'Synthesis:' prefix and 'one-shot' phrasing make the intended use case clear: get a comprehensive overview of a gene instead of calling individual locus tools. It does not explicitly name alternatives or exclusions, but the dossier framing differentiates it from the granular sibling 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: it explains the data source, the resolution process (locus to gene coordinates), the variant_count vs capped list behavior, and the 'truncated' flag. No contradictions.
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, front-loaded with core purpose, immediately followed by essential details. No filler; every clause adds value.
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?
Despite the tool's moderate complexity (3 parameters, external API, multiple organisms, output cap), the description covers all essential aspects: source, data content, organism support, cap behavior, and sibling differentiation. Output schema exists, so return values need not be elaborated.
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 100%, so baseline is 3. The description adds meaning beyond schema by providing examples for locus (AT1G01010), clarifying organism parameter accepted formats (slug, name, taxid), and explaining the limit parameter's cap and truncation reporting.
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 lists natural variants overlapping a locus's genomic span, specifying the source (Ensembl via EVA/dbSNP), the data fields returned, and explicitly distinguishes it from sibling tools (get_sequence, ensembl_region_query). The verb 'list' and resource 'variants' are 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 provides clear context for when to use the tool (to retrieve germline variants) and explicitly names two alternatives it is distinct from. However, it does not elaborate on when not to use it or list other possible alternatives among the many sibling 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?
Annotations already declare read-only, idempotent, not destructive. Description adds that it is free, no key, returns found=false when unclassifiable, and sources from pantherdb.org. Adds behavioral context beyond annotations.
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 efficient sentences that front-load the action and output, then add context on usage. No wasted words.
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?
Given the complexity (multiple output types, 2 parameters, 12 organisms), the description covers all key aspects: data returned, behavior when no classification, source, default organism, and complementary relationship to siblings.
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 100%, but description adds concrete examples for locus (e.g., AT1G01060) and explains organism accepts canonical slug, scientific/common name, or NCBI taxid. Adds value beyond 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?
Clearly states it fetches PANTHER classification for a locus, listing returns (family/subfamily IDs/names, GO terms, protein class, pathways). Distinguishes itself from sequence-homology tools (gramene_homologs/consensus_homologs) by offering an evolutionary-family view.
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?
Explicitly says it complements sequence-homology tools, implying when to use. Specifies it works for all 12 organisms and defaults to arabidopsis_thaliana. Could be more explicit about when not to use, but the complementary statement provides 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds organism dispatch logic, response shape differences, and format requirements for rice. No contradictions, and adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core purpose and is well-structured. Every sentence adds value, though it is somewhat lengthy due to necessary detail. No redundancy.
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?
Given the complexity (organism-specific endpoints, response shapes, format requirements, error handling), the description covers all needed context. Output schema exists, so return values need not be detailed.
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 100% with descriptions for both parameters. The description adds meaning by explaining locus format (AGI vs. MSU) and the effect of the organism parameter on the response shape, complementing the 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 it fetches BAR AIV interactions for Arabidopsis or rice locus, specifying endpoints and response shapes per organism. It clearly distinguishes from siblings by organism-specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (Arabidopsis or rice locus) and when not to (other organisms raise OrganismNotSupported). Also notes rice requires MSU format, rejecting RAP-DB. Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral detail: the two-stage fanout, per-locus error handling (NotFoundError into errors[] with typed prefix), and the 50-locus cap. This goes well beyond the annotations.
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 four sentences, each adding distinct information: purpose, process, error behavior, and cap. No unnecessary words; front-loaded with the most important information (batch variant).
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 the complexity of a batch tool with a two-stage process, the description covers the key aspects. It mentions error handling and the cap. However, it could benefit from a brief note on when to prefer this over other batch tools or the single-locus version, though the tool name and sibling set provide some 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?
Schema coverage is 100%, and the description adds context about error handling for the 'loci' parameter (how errors are structured). It also clarifies the default for 'organism' and the range for 'limit'. This adds value beyond the 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?
Description clearly states it is a batch variant of locus_go_annotations, specifies the two-stage fanout (locus to UniProt to QuickGO), and includes a cap of 50 loci. This distinguishes it from the single-locus sibling tool.
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 implies use for multiple loci by being a batch variant, and mentions the cap of 50 loci. However, it does not explicitly state when not to use it or compare with other batch tools (e.g., batch_locus_literature) to avoid confusion.
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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: aggregation of ThaleMine rows into one entry per partner, ordering by evidence_count, error behavior for unknown loci (NotFoundError), and organism restriction. No contradictions with annotations.
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 detailed but front-loaded with the core purpose. It contains two paragraphs with necessary specifics (aggregation, sources, error cases). Slightly longer than minimal but every sentence adds value; no redundant 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?
Given the complexity of the tool (aggregation, multiple source databases, error conditions, organism restriction), the description covers all aspects: what is returned, how results are ordered, what found=false means, and organism limitation. Output schema exists, so return format details not needed. Very 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 covers 100%, but description adds context: loci format example ('AT5G11260 (HY5)'), organism default value, and that ThaleMine only supports Arabidopsis. This adds meaning beyond the schema definition.
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 ('Fetch CURATED EXPERIMENTAL protein/genetic interaction partners'), the resource ('ThaleMine'), the organism ('Arabidopsis'), and distinguishes from sibling tools (string_interactions, bar_aiv_interactions) by emphasizing experimental provenance and curation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with sibling tools: 'Unlike string_interactions (predicted / text-mined, scored) and bar_aiv_interactions (which returns GRN paper references...), every partner here carries the actual experimental provenance.' It also clarifies when the tool returns no results (found=false) and restricts to Arabidopsis, setting clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses resolution process, return format, error behavior (NotFoundError), and that structure_count is true total. Consistent with readOnly/idiempotent annotations.
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?
Well-structured, front-loaded, each sentence adds value. Slightly verbose but still concise.
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?
Covers error cases, normal outcomes, data fields, complements siblings. Output schema and annotations further reduce burden.
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?
Adds context beyond schema: explains locus resolution, organism defaults/accepts multiple forms, and example values. Schema coverage was already 100%.
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?
Clearly states it fetches experimentally-solved structures for a locus, specifies methods (X-ray, cryo-EM, NMR), and differentiates from alphafold_structure.
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 context about when to use (experimental vs predicted) and normal outcomes (found=false for most plants). Could explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral details beyond annotations: the resolution from locus to UniProt, return structure (entries with fields, count_by_type), error handling (NotFoundError for locus without UniProt, empty list for no domains), and pagination note (domain_count is true total).
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 well-structured, starting with the main purpose. Each sentence adds meaningful information, though it could be slightly more concise. Overall, it earns its length.
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?
Given the tool's complexity (2 parameters, output schema exists, rich annotations), the description covers resolution steps, error scenarios, and output fields. The presence of an output schema reduces the burden, but the description still adds important contextual details.
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 100%, so baseline is 3. The description adds value by providing examples for the 'locus' parameter and explaining the format for 'organism' (canonical slug, scientific/common name, NCBI taxid), which goes beyond the 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 clearly states the verb 'Fetch' and resource 'InterPro domain / family architecture'. It distinguishes from sibling tools by noting that Pfam appears as a source_database within this tool, not as a separate tool.
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: for fetching InterPro domain architecture for a locus. It specifies default organism and how to specify others. It lacks explicit exclusions or alternatives, but the context is sufficient.
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?
Description adds context beyond annotations (readOnlyHint, idempotentHint) by detailing the source URL and return field names. No contradictions; it complements annotation with operational details.
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 efficiently convey purpose, defaults, parameter formats, and return fields. Information is front-loaded and every sentence adds value.
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?
Given the presence of an output schema (implied by return field list) and strong annotations, the description fully covers what the tool does, its parameters, and return values. No gaps for a lookup 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 coverage is 100% with both parameters described. Description adds examples for locus format and clarifies organism parameter accepts multiple name forms, enhancing understanding beyond 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 clearly states the tool fetches a gene record from Phytozome BioMart, specifying the data source and return fields. It distinguishes from siblings like ensembl_plants_lookup_locus by naming the specific database.
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?
Description explains defaults (arabidopsis_thaliana) and how to specify organism via slug, name, or taxid. It implies usage context for Phytozome genes but could be more explicit about when to choose this over alternative tools for other databases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, conveying safety. The description adds critical behavioral detail: it prefers Swiss-Prot and falls back to TrEMBL, which is beyond annotation scope.
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 well-structured with a clear first sentence, followed by details. It is not overly verbose, though the return field list could be moved to the output schema. Every sentence is informative.
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?
Given the tool's simplicity (2 params, clear schema, output schema exists, annotations cover safety), the description covers purpose, usage, parameter details, fallback logic, and pairing guidance. It is comprehensive.
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 100% with descriptions for both parameters, so baseline is 3. The description adds value by explicitly listing accepted formats for organism (slug, name, taxid) and providing examples, enhancing understanding.
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 it resolves a plant locus to its canonical UniProtKB record, specifying the verb, resource, and scope. It differentiates from siblings by calling it the 'protein-side entry point' and listing paired tools.
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 advises pairing with InterPro, AlphaFold, etc., indicating when to use this tool. However, it does not explicitly contrast with alternative locus tools or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, idempotent, read-only. The description adds significant behavioral context: free API, no key needed, returns most-severe consequence per transcript, found=false when no features, works for 12 organisms, default organism, and output format. Adds value beyond annotations with no contradictions.
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 well-structured with front-loaded core purpose, followed by details on input, output, and scope. While it is on the longer side, all sentences provide useful information and are necessary given the tool's complexity.
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?
The tool has 3 parameters (100% schema coverage), an output schema, and clear annotations. The description covers remaining aspects: free API, organism support, found flag, and consequence detail. Everything an agent needs is 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?
Schema coverage is 100%, so baseline is 3. The description enriches parameters with format examples for region (chr:start-end:strand), allele example ('C'), and organism accepted types (slug, name, taxid) and default. This provides valuable guidance beyond 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 specific verb 'predict' and resource 'molecular consequences with Ensembl VEP'. It explicitly states the tool is variant-first (not locus-first), and distinguishes from sibling tools that handle loci or other analyses, making 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (variant effect prediction), specifies variant-first approach, and provides examples of input format. It does not explicitly exclude alternative tools but implies context through sibling list; clear usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), it adds behavioral details: free, no key, per-SNP return, variant_count behavior, scoping of locus with .1, and error condition. Adds significant value.
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?
Description is concise and well-structured, front-loading purpose. Every sentence adds essential information with no redundancy.
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?
Given full schema coverage, annotations, and output schema presence, the description is complete. It covers purpose, usage constraints, parameter details, and return structure adequately.
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 100%, so baseline 3. The description adds details: locus expects AGI format with transcript scoping, organism defaults and is Arabidopsis-only. Adds meaningful guidance beyond 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 clearly states it fetches '1001 Genomes natural-variation SNP effects for an Arabidopsis locus', with a specific verb and resource. It distinguishes from siblings by focusing on variation data, unlike motif, homolog, expression tools.
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 explicitly states the tool is Arabidopsis-only and provides the default organism. It does not directly compare to siblings but the context makes it clear when to use (for variation). No explicit when-not-to-use, but strong context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses retry behavior (429/5xx via _http helper, Retry-After capped at 60s), explains error handling (misses in errors[] with prefix), and notes result shape matches single-locus tool. Adds value beyond annotations.
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, front-loaded with purpose, no redundancy. Every sentence adds value.
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?
Given batch complexity, error handling, and cost benefit, the description is thorough. Output schema exists, annotations cover safety, so all behavioral aspects are addressed.
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 100%, so baseline 3. Description adds that loci max is 50 and clarifies error structure, providing context beyond 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?
Clearly states it's a batch variant of a single-locus tool, uses POST /lookup/id endpoint for up to 50 loci, and highlights cost efficiency. Distinguishes from sibling 'ensembl_plants_lookup_locus'.
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?
Implicitly guides use for multiple loci via 'batch variant' and 'cheaper than N parallel GETs'. No explicit when-not or alternative mentions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral details beyond annotations: async Put/Get, polling with 60s floor, progress notifications, long search error with RID preservation, email requirement. No contradiction with annotations.
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?
Every sentence adds value; no fluff. Front-loaded with main purpose. Length is appropriate for complexity.
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?
Given complexity (async, polling, error handling, many parameters) and presence of output schema, description covers essential behavior, defaults, error case, and environmental setup. Complete enough.
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 covers 100% of parameters with descriptions. Description adds value by summarizing program/database defaults and explaining notable parameters like megablast and poll interval, but does not add fundamental new 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?
Clearly states it runs a BLAST sequence-similarity search against NCBI. Verb+resource is specific ('Run' + 'BLAST sequence-similarity search'). Distinguished from sibling tools as the only BLAST tool.
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 use (sequence similarity search) but does not explicitly state when not to use or mention alternatives. However, sibling tools are not BLAST-related, so implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: default parameters, seq_type enum options (including that 'protein' is the canonical-transcript product), and organism flexibility. No contradictions.
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 extremely concise (two sentences of functional content plus one sentence of usage guidance) and front-loaded. Every sentence adds essential information without redundancy.
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?
Given the low parameter count, high schema coverage, and presence of output schema, the description is complete. It covers purpose, parameters with defaults, usage scenario, and chaining to sibling tools. No gaps remain for the agent to guess.
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 100%, but the description adds meaning beyond the schema by clarifying the default values for organism and seq_type, and explaining the seq_type mapping to BLAST types (protein for blastp, cds/cdna for blastn). This provides practical usage context not present in the 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 clearly states the tool fetches a locus's sequence from Ensembl Plants, specifying verb 'Fetch' and resource 'sequence'. It distinguishes from siblings by focusing on sequence retrieval, which is unique among the listed tools.
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 explicit guidance on chaining the output to blast_sequence for different seq_types, and mentions defaults for organism. It doesn't explicitly exclude alternative uses but gives strong contextual cues for when 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds significant behavioral context: it names the upstream service (g:Profiler), notes it's free and requires no API key, explains the return of unmapped loci for detecting namespace mismatches, and describes the significance correction (g:SCS). No contradictions with annotations.
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 a single paragraph with each sentence contributing essential information. It starts with the core purpose, then immediately differentiates from sibling, explains key parameters, and notes return values. No filler; every sentence earns its place.
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?
Given the tool's complexity (6 parameters, 1 required, output schema present, extensive annotations), the description covers all essential aspects: purpose, usage context, parameter behavior, service details, return format, and organism defaults. It is fully sufficient for an AI agent to select and invoke 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?
Schema coverage is 100% with descriptions per parameter. The description adds value by explaining the role of 'loci' with examples, summarizing default behavior for sources and thresholds, and clarifying the purpose of optional parameters like background. This goes beyond the schema's structural 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 clearly states it performs GO/KEGG over-representation analysis for a gene list, and explicitly contrasts with the sibling tool 'locus_go_annotations' which handles single loci. The verb 'answers what is my gene SET enriched for?' is specific and distinguishes the tool's 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 clear guidance by contrasting with locus_go_annotations and contextualizing the tool for differential-expression or co-expression cluster analysis. It could be improved with explicit when-not-to-use scenarios, but the sibling differentiation is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors beyond annotations: that organism count is the true cluster total, member list is capped with truncated flagged, and organism is only validated and echoed. This adds significant value to the readOnlyHint and idempotentHint already present.
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 well-structured with key information front-loaded (purpose, data source, free use). While slightly verbose, every sentence adds value and the length is justified by the complexity of the tool's behavior.
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?
Covers all necessary aspects: data source, taxonomic scope, return fields, truncation behavior, handling of missing results, and organism parameter validation. Given the existing output schema, this provides a complete picture.
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?
Adds substantial meaning beyond the input schema: explains the organism parameter's non-scoping behavior, describes truncation logic for limit, and provides an example for locus. With 100% schema coverage, this goes well beyond baseline.
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 resolves a locus to its OrthoDB ortholog group and returns cross-species member genes. It also explicitly distinguishes itself from other locus tools by noting that the organism parameter does not scope the search, setting it apart from siblings.
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 guidance on when to use (for ortholog resolution at Viridiplantae level) and explicitly warns that organism does not scope the search. However, it could more directly state which alternative tools to use for other types of homology searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive, and open-world. The description adds: external database access (alphafold.ebi.ac.uk), free no key requirement, and specific error handling (found=false vs NotFoundError). No contradictions.
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 approximately 100 words, front-loaded with the main action, and each sentence adds value. No redundant or vague statements.
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?
Given the output schema exists, the description covers all necessary aspects: source, free usage, workflow, edge cases, default organism, and sibling relation. It is complete and informative.
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 100%, baseline 3. The description adds concrete examples for locus (AT4G09760, Os01g0100100) and explains organism accepts slugs, names, or taxids. This provides significant extra meaning beyond the 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 clearly states it fetches the AlphaFold DB predicted-structure summary for a locus, specifying the source and that it's free. It distinguishes from the sibling tool resolve_locus_to_uniprot by noting it provides the structure-level view, complementing the sequence-level view.
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 explains the workflow (resolves locus to UniProt, returns specific data), handles edge cases (found=false for missing model, NotFoundError for invalid locus), and states the default organism. It mentions the sibling tool relation, but lacks explicit 'use this when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds behavioral context: fan-out in parallel, up to 50 loci, result structure, and organism restriction. No contradiction with annotations.
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?
Three sentences, front-loaded with purpose and constraints. No extraneous information. Every sentence adds value (batch variant, parallel fan-out, payload summary, organism restriction).
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?
Given that an output schema exists (as per context), the description sufficiently explains return values without needing full schema details. Covers key payload fields and error handling, and includes scope (Arabidopsis) and limits (50 loci).
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 100% with a description for the loci parameter. Description adds meaning about array items and error handling ('Successes land in results[locus]; PlantGenomicsError failures in errors[locus]'), which goes beyond the schema-provided 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?
Clearly states it's a batch variant of bar_gene_summary, describes parallel fan-out over up to 50 loci, and specifies the output structure (curator summary, computational description, NCBI Gene ID, cross-DB aliases). Distinguishes from sibling bar_gene_summary by being batch and from other batch tools by specifying the exact per-locus payload.
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?
Explicitly says 'Batch variant of bar_gene_summary' and 'Arabidopsis only', implying use for multiple loci. Does not explicitly state when not to use (e.g., for single locus), but the context is clear. Provides information about parallel execution and payload structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already present. Description adds return structure (count, raw xref list, by_db rollup) and dbname key explanation, going beyond annotations.
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, front-loaded with action, no wasted words. Every sentence adds value.
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?
Given output schema exists, description covers inputs, defaults, and output structure sufficiently. No gaps.
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 covers both parameters fully. Description adds examples (locus), explains organism accepts various forms (slug, name, taxid), enriching 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?
Clear verb 'Fetch' with specific resource 'cross-database references for a plant locus from Ensembl Plants'. Distinct from sibling tools like batch_get_gene_xrefs and resolve_locus_to_uniprot.
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 default organism and how to use for other species. Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it notes the free access, no API key requirement, result caps and defaults, return fields, and the disambiguation strategy for non-Arabidopsis species. All align with the readOnlyHint and idempotentHint annotations.
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 concise and front-loaded, with no wasted words. Every sentence provides unique value: purpose, constraints, return fields, disambiguation behavior, and usage pairing. It is appropriately sized for the tool's complexity.
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?
Given the tool's moderate complexity (4 parameters, output schema present), the description comprehensively covers purpose, behavior, parameter details, return fields, and usage context. The existence of an output schema reduces the need to detail return structure, and the description fills the remaining gaps.
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 100%, but the description still adds meaning: it explains the cap on 'size', provides example inputs for 'locus' and 'organism', and clarifies the effect of 'include_abstract' (null out abstractText and reduce payload). This enhances understanding beyond the 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 clearly states the verb 'Search' and the resource 'Europe PMC' for literature mentioning a plant locus. It distinguishes this tool from siblings by specifying its unique function of literature search, as opposed to other locus-related tools like orthology or expression.
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 guidance on when to use the tool, e.g., for searching literature given a locus, and suggests pairing with resolution tools. It explains how non-Arabidopsis queries are handled. However, it does not explicitly state when not to use it or mention alternatives among sibling tools, which are mostly non-literature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral traits beyond annotations: it resolves locus to UniProt, confirms hits by accession matching, returns name_only_matches separately, explains coverage biases, and clarifies normal outcomes. Annotations only provide basic hints.
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 well-structured and front-loaded with the core purpose. Every sentence adds value, explaining the process, important caveats, and usage. It is concise given the tool's complexity.
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?
The description covers all key aspects: what the tool does, how it works, what is returned, important behavioral notes, coverage limitations, and relation to siblings. The existence of an output schema complements the description.
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 covers both parameters with descriptions. The description adds meaning by explaining the default organism, accepted formats, and providing locus examples. This enriches the semantic understanding.
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 fetches curated transcription-factor DNA binding motifs for a locus from JASPAR. It specifies the source, the process, and what is returned, and distinguishes from sibling tool jaspar_motif.
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 guidance on when to use this tool by noting that jaspar_motif is for raw matrices, and explains that found=false is a normal outcome. It also contrasts with sibling tools implicitly. However, it does not explicitly list 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds crucial behavioral context: case-sensitivity of KEGG v118+, the HTTP source (rest.kegg.jp), and the error behavior for unsupported organisms. No contradictions.
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 a single paragraph, front-loaded with purpose, but the multi-organism caveat is detailed. Each sentence adds value, but could be tightened slightly.
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 tool with output schema, good annotations, and 2 parameters, the description covers limitations, usage context, and partner tools. It is complete.
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 100%, but description adds value: for 'locus', it stresses case-preservation and sensitivity; for 'organism', it explains the limitation and error. This goes beyond the schema's basic 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 states a specific verb+resource ('Fetch KEGG pathway memberships for an Arabidopsis locus') and lists the return types (pathway IDs, names, categories). It distinguishes from siblings by mentioning pairing with locus_go_annotations and noting the organism limitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for pathway memberships), when not to (other organisms raise OrganismNotSupported), and suggests pairing with locus_go_annotations. The multi-organism caveat provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important behavioral context: upstream order is preserved, 'truncated' means later statements cut, and an unknown locus raises a 'typed NotFoundError'. No contradictions with annotations.
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 detailed and front-loaded with the main action, but some sentences (e.g., the example HY5 count) are slightly verbose. However, every sentence adds useful information, and the structure is logical. Could be slightly trimmed without losing value.
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?
Given the complexity (curated statements, ordering, truncation, errors, organism restriction) and the presence of an output schema (so return values need not be described), the description covers all necessary behavioral and contextual details. It differentiates well from many sibling tools and handles edge cases (found=false, unknown locus).
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 100%, but the description adds value beyond schema: it gives an example value for 'locus' (AT5G11260), explains what 'organism' accepts (slug, scientific name, common name, or NCBI taxid), and clarifies the default and limitation (Arabidopsis only). This enriches parameter understanding.
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 it fetches 'curated GeneRIF functional statements for an Arabidopsis locus from ThaleMine', clearly specifying verb, resource, and source. It distinguishes from siblings 'locus_go_annotations' and 'locus_literature' by explaining that GeneRIFs provide 'dense, directly citable functional context' that those do not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: when needing 'directly citable functional context' that GO terms and abstracts lack. It provides an example (HY5 with 114 statements) and explains the meaning of 'found=false' and error behavior for unknown loci. It also notes 'ThaleMine supports Arabidopsis only', setting clear scope and restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotent, read-only, non-destructive hints. The description adds valuable behavioral details: it returns curator summary, computational description, NCBI Gene ID, and cross-database aliases, and identifies the data source. No contradictions.
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, conveying essential information in two sentences with no redundancy. Every sentence adds value.
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?
Given the presence of an output schema (not shown), the description appropriately omits return value details. It covers purpose, source, scope, and relationship to siblings, which is complete for a single-parameter 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?
Schema coverage is 100% for the single 'locus' parameter, with a descriptive example. The description adds the Arabidopsis-only restriction, which provides semantic context beyond the schema. This justifies a score above the baseline of 3.
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 fetches a TAIR curator-vetted Arabidopsis locus summary. It specifies the resource (BAR/ThaleMine) and distinguishes itself from siblings by mentioning it's an alias of bar_gene_summary and restricted to Arabidopsis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (for TAIR-style curator summaries), notes it is specific to Arabidopsis, and provides context that it replaces a paid TAIR API. The alias reference clarifies its relationship to bar_gene_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate safe, idempotent read operation. Description adds key limitations (no per-row taxon/identity/protein ID) and details return structure, enhancing beyond annotations.
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?
Three-sentence paragraph that is direct and informative without redundancy.
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?
Given output schema exists, description covers return fields and provides integration guidance, fully addressing the tool's complexity.
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 100%. Description adds value with examples for locus, explains default and behavior for homology_type, and clarifies limit reporting (total, truncated).
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?
Clearly states it fetches orthologs and paralogs for a plant locus from Gramene compara, specifying data source and version. Differentiates from siblings by naming Gramene and offering homology_type options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit defaults and alternatives (ortholog, paralog, all) and suggests complementary tools (resolve_locus_to_uniprot, blast_sequence) for enriched analysis.
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:

[![plant-genomics-mcp MCP server](https://glama.ai/mcp/servers/musharna/plant-genomics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/musharna/plant-genomics-mcp)

Score Badge

Copy to your README.md:

[![plant-genomics-mcp MCP server](https://glama.ai/mcp/servers/musharna/plant-genomics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/musharna/plant-genomics-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/musharna/plant-genomics-mcp'

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