AGR MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v5.0.2
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between search_genes and find_orthologs (both involve gene-related queries across species), and between mine_query, mine_query_builder, and mine_natural_query (all for querying AllianceMine, though they differ in input format). The descriptions help clarify these distinctions, but an agent might occasionally misselect between them.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., get_gene_info, search_genes, mine_create_list), but there are minor deviations like mine_natural_query (which uses 'natural' as an adjective) and the mix of 'get' vs. 'search' prefixes for similar actions. Overall, the pattern is predictable and readable.
Tool Count3/5
With 22 tools, the count feels borderline heavy for a genomics server, though it covers both gene data retrieval and AllianceMine operations. It might overwhelm agents with too many options, but the scope is broad enough to justify a larger set, making it reasonable but not ideal.
Completeness5/5
The tool set provides comprehensive coverage for the domain of genomic data and AllianceMine interactions. It includes CRUD operations for lists (create, get, delete, add), extensive gene data retrieval (info, expression, diseases, etc.), and multiple query methods (search, templates, natural language, structured), leaving no obvious gaps for agent workflows.
Average 3.2/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or response format. For a tool with no annotations, this leaves significant behavioral gaps, though it doesn't contradict any 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, efficient sentence that front-loads the core purpose without unnecessary details. Every word contributes to understanding what the tool does, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves expression data. It doesn't explain the return format, potential data structures, or how results are organized (e.g., pagination with the 'limit' parameter). For a data-fetching tool with two parameters, this leaves the agent underinformed about what to expect.
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%, with both parameters ('gene_id' and 'limit') well-documented in the schema. The description adds no additional parameter semantics beyond implying that expression data includes tissue/cell type and developmental stages, which relates to output rather than inputs. This meets the baseline for high schema coverage but doesn't enhance understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'expression data for a gene', specifying what data is retrieved (tissue/cell type expression and developmental stages). It distinguishes from siblings like 'get_gene_info' or 'get_gene_diseases' by focusing on expression data, though it doesn't explicitly name alternatives. The purpose is specific but could be more explicit about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare to sibling tools like 'search_genes' or 'get_gene_info', leaving the agent to infer usage based on the purpose alone. This lack of explicit context reduces effectiveness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves interactions but does not specify whether this is a read-only operation, potential rate limits, authentication needs, or what the output format might be (e.g., list of interactions, structured data). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not address behavioral aspects like safety, performance, or output format, which are crucial for an agent to use the tool effectively. For a tool with two parameters and no structured output information, more context is needed to ensure proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('gene_id' and 'limit') clearly documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples of gene identifiers or implications of the limit parameter. Baseline 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('molecular and genetic interactions for a gene'), making the purpose immediately understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_gene_info' or 'get_gene_expression', which might also involve gene-related data retrieval, leaving room for ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'search_genes' or other gene-specific tools like 'get_gene_diseases'. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this is a read-only operation, if there are rate limits, what the output format might be, or any constraints beyond the parameters, making it insufficient for safe and effective use.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what phenotype annotations entail, the format of results, or any behavioral traits like pagination or error handling. For a tool with two parameters and no structured output, more context is needed to ensure proper usage.
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 description doesn't add any meaning beyond the input schema, which has 100% coverage with clear descriptions for 'gene_id' and 'limit'. Since the schema fully documents the parameters, the baseline score of 3 is appropriate, as no additional semantic context is provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'phenotype annotations for a gene', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_gene_diseases' or 'get_gene_expression', which also retrieve annotations for genes but for different data types, leaving room for confusion about what distinguishes this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_gene_diseases' and 'get_gene_expression' that also fetch gene-related annotations, there's no indication of what makes phenotype annotations unique or when to choose this over other gene annotation tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the ALLIANCEMINE_TOKEN requirement (useful auth context), but fails to describe what happens when items are added (e.g., duplicates, ordering, success/failure response), rate limits, or whether this is a safe mutation operation versus a destructive one.
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 with just two sentences, both of which earn their place: the first states the core functionality, the second provides critical authentication requirement. There's zero wasted verbiage and it's perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after items are added (success indicators, error conditions, return values), nor does it address behavioral aspects like idempotency, duplicate handling, or permission requirements beyond the token.
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 fully documents both parameters (name and identifiers). The description adds no additional meaning about parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add items') and resource ('to an existing list'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'mine_create_list' (which creates lists) or 'mine_get_list' (which retrieves lists), missing an opportunity for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mine_create_list' (for creating new lists) or 'mine_get_list' (for retrieving lists). It mentions an environment variable requirement but offers no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions an authentication requirement, which is useful context, but fails to describe other critical traits: it doesn't clarify if this is a mutation (implied by 'Create' but not stated), what happens on success/failure, whether identifiers are validated, or any rate limits. For a creation tool with zero annotation coverage, this leaves significant gaps.
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, efficient sentence that front-loads the core action ('Create a new list') and includes essential authentication info. There's no wasted text, though it could be slightly more structured by separating purpose from prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral outcomes (e.g., what's returned, error handling), doesn't explain the relationship between parameters like 'type' and 'identifiers', and offers minimal guidance beyond authentication. For a 4-parameter mutation tool, this is inadequate.
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 fully documents all parameters (name, type, identifiers, description). The description adds no additional meaning beyond what the schema provides, such as examples or constraints on 'type' values. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('a new list in AllianceMine'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'mine_add_to_list' or 'mine_list_templates', which could involve list creation or management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an authentication requirement ('Requires ALLIANCEMINE_TOKEN environment variable'), which provides some context for when to use it, but offers no guidance on when to choose this tool over alternatives like 'mine_add_to_list' for adding to existing lists or 'mine_list_templates' for template-based creation. No explicit when-not-to-use or sibling comparisons are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the authentication requirement (ALLIANCEMINE_TOKEN), which is useful context. However, it doesn't describe behavioral traits like whether deletion is permanent/reversible, what happens to list contents, error conditions, or rate limits—significant gaps for a destructive operation.
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, efficient sentence that front-loads the core action ('Delete a list from AllianceMine') and includes essential context (authentication requirement). Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical details like confirmation prompts, return values, error handling, or impact on related data, leaving the agent with insufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'name' documented as 'List name to delete'. The description adds no additional meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a list from AllianceMine'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'mine_get_list' or 'mine_get_lists', which would require 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the ALLIANCEMINE_TOKEN requirement, which is a prerequisite, but offers no guidance on when to use this tool versus alternatives like 'mine_get_list' for reading lists or 'mine_create_list' for creating them. There's no explicit when/when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it 'gets' contents, implying a read-only operation, but doesn't clarify if this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, clear sentence with no wasted words, making it easy to parse. It's front-loaded with the core purpose ('Get the contents'), and every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what 'contents' entails (e.g., items, metadata, structure), potential return formats, or error conditions. For a read operation with no structured output documentation, this leaves the agent with insufficient context to use it effectively.
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% description coverage, with the 'name' parameter documented as 'List name'. The description adds no additional semantic context beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('contents of a specific list'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'mine_get_lists' (which likely lists available lists rather than contents) or 'mine_create_list' (which creates lists), leaving room for ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'mine_get_lists' (likely for listing lists) and 'mine_query' (for broader queries), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a 'Get' operation, implying read-only behavior, but doesn't mention potential side effects, authentication needs, rate limits, or response format. For a tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective use. It doesn't explain what 'lists' entail (e.g., format, content), how results are returned, or any constraints like pagination. For a tool with no structured behavioral data, more context is needed to ensure reliable agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'type' documented as 'Filter by type: Gene, Protein, etc.' The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all available gene/protein lists in AllianceMine'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'mine_get_list' (singular) or 'mine_list_templates', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'mine_get_list' (singular) or 'mine_list_templates'. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the search action but lacks behavioral details such as whether it's read-only, how results are returned (e.g., pagination, format), rate limits, or authentication needs. For a search tool with no annotations, this is insufficient to inform the agent adequately.
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, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language and avoids redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks information on behavioral traits, output format, and usage context relative to siblings. For a search tool in a crowded namespace, more guidance is needed to ensure the agent can use it effectively.
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 parameters (query, type, limit). The description adds minimal value by listing entity types (genes, proteins, diseases) that align with the 'type' parameter but doesn't provide additional syntax or constraints beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search AllianceMine for genes, proteins, diseases, and other biological entities using keyword search.' It specifies the verb (search), resource (AllianceMine), and target entities. However, it doesn't explicitly differentiate from siblings like 'mine_query' or 'search_genes' beyond the broader entity scope, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'mine_query', 'search_genes', 'search_diseases'), it fails to specify scenarios where this general keyword search is preferred over more specialized tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search function without details on permissions, rate limits, result format, or pagination. For a search tool with zero annotation coverage, this is inadequate.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, result structure, and usage context, which are essential for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'query' and 'limit' parameters. The description adds no additional meaning beyond the schema, such as query syntax examples or result ordering. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for') and resource ('alleles/variants in the Alliance database'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search_genes' or 'search_diseases', which also search the same database but for different resources, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_gene_alleles' for allele retrieval by gene or 'mine_search' for broader queries, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, what authentication might be required, rate limits, or what format results will be returned in. The description simply states what the tool does without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a search tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of results to expect, how results are structured, or any limitations of the search. Given the context of a database search operation, more information about behavior and output would be expected.
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%, with both parameters well-documented in the schema. The description doesn't add any meaningful parameter information beyond what's already in the schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for diseases') and resource ('Alliance database'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'search_genes' or 'search_alleles' beyond specifying the disease domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mine_search' or 'mine_natural_query' from the sibling list. It lacks any context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Supports species filtering' but fails to describe critical behaviors such as search algorithm (e.g., fuzzy matching), pagination, rate limits, authentication needs, or what the output looks like (e.g., list of gene objects). This is inadequate for a search tool with zero annotation coverage.
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 with two sentences that are front-loaded and waste no words. Every sentence contributes directly to understanding the tool's purpose and scope, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on output format, error handling, behavioral constraints, and how it differs from siblings. For a tool with 3 parameters and rich sibling context, this minimal description leaves significant gaps for an AI agent.
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 thoroughly. The description adds minimal value beyond the schema by implying species filtering is a feature, but doesn't provide additional syntax, format details, or examples beyond what's in the parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for genes') and scope ('across all Alliance of Genome Resources model organisms'), which distinguishes it from siblings like search_alleles or search_diseases. However, it doesn't specify the exact resource type beyond 'genes' or mention what information is returned, making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions species filtering but provides no explicit guidance on when to use this tool versus alternatives like get_gene_info or mine_search. It lacks context about use cases, prerequisites, or comparisons with sibling tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool finds orthologs and returns homologs from all Alliance model organisms, which gives some behavioral context (e.g., cross-species focus, data source). However, it lacks details on permissions, rate limits, error handling, or what 'orthologous genes' entails operationally (e.g., algorithm, confidence thresholds). For a tool with no annotations, this is insufficient, scoring 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the tool's function and scope without waste. It is front-loaded with the core purpose and adds necessary context about the data source. Every sentence earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (finding orthologs across species), no annotations, no output schema, and 1 parameter with full schema coverage, the description is partially complete. It covers what the tool does and the data source but lacks details on output format, behavioral traits, or usage context. This makes it adequate but with clear gaps, scoring 3 as the minimum viable.
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 1 parameter with 100% description coverage ('Gene identifier'), so the schema does the heavy lifting. The description adds no additional parameter semantics beyond implying the gene_id is used to find orthologs. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find orthologous genes across species' specifies the action and resource. It distinguishes from siblings like get_gene_info or search_genes by focusing on cross-species homology rather than gene-specific data or general search. However, it doesn't explicitly differentiate from potential overlap with other homology tools not listed, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'Returns homologs from all Alliance model organisms,' which implies a broad scope but doesn't specify when to choose this over sibling tools like get_gene_info for single-species data or search_genes for queries. Without clear when/when-not instructions or named alternatives, it scores 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not cover aspects like rate limits, authentication needs, error handling, or response format. For a tool with no annotations, this is a significant gap in transparency.
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, efficient sentence: 'Get alleles/variants associated with a gene.' It is front-loaded with the core purpose, has no redundant words, and every part earns its place. This makes it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on behavior, usage guidelines, and output. Without annotations or an output schema, more context on what the tool returns would be beneficial, but it meets a basic threshold for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond what the input schema provides. Schema description coverage is 100%, with clear documentation for 'gene_id' and 'limit' parameters. The description mentions 'alleles/variants associated with a gene,' which aligns with 'gene_id,' but offers no additional context on parameter usage or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get alleles/variants associated with a gene.' It specifies the verb 'Get' and the resource 'alleles/variants associated with a gene,' making the action and target clear. However, it does not explicitly differentiate from sibling tools like 'search_alleles,' which might have overlapping functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'search_alleles' or 'get_gene_info,' nor does it specify prerequisites, exclusions, or contextual usage. This lack of guidance leaves the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns 'schema information' but doesn't clarify what that entails (e.g., structure, format, or limitations). It also omits details like error handling, performance characteristics, or any constraints on the natural language processing, leaving significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the tool's purpose and outcome. There's no unnecessary information, and it efficiently communicates the core functionality without waste, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of processing natural language queries and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'schema information' is returned, how it should be used with 'mine_query_builder,' or any behavioral traits. This leaves the agent with insufficient context to effectively invoke the tool or interpret results.
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%, with both parameters ('query' and 'limit') well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints on the 'query' input. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Process a natural language query and return schema information to construct a structured AllianceMine query.' It specifies the verb ('process'), resource ('natural language query'), and outcome ('return schema information'). However, it doesn't explicitly differentiate from sibling tools like 'mine_query_builder' or 'mine_search' beyond mentioning the latter as a follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it helps 'convert the user's natural language into a mine_query_builder call,' suggesting this is a preparatory step. However, it lacks explicit guidance on when to use this tool versus alternatives like 'mine_query' or 'mine_search,' and doesn't specify prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list but doesn't add context like whether it's a read-only operation, if there are rate limits, or what the return format might be (e.g., pagination, structure). This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior or output, which could be helpful for an agent to understand the full context, especially without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description doesn't add param info, but that's acceptable here as there are no params to explain, so it meets the baseline for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and the resource ('model organisms supported by Alliance of Genome Resources'), providing a specific purpose. However, it doesn't explicitly differentiate this tool from its siblings (like 'search_genes' or 'mine_search'), which focus on different data types or operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for browsing all organisms versus filtering specific ones, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists templates but doesn't disclose behavioral traits like pagination, sorting, error conditions, or response format. The description is minimal but accurate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the purpose, and the second provides helpful context about templates. It's front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It explains what the tool does but lacks details on output format or usage context, which could help an agent use it more effectively. It meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is applied for zero-parameter tools with full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('available query templates in AllianceMine'), and explains what templates are ('pre-built queries for common use cases'). It doesn't explicitly differentiate from siblings like 'mine_query_builder' or 'mine_run_template', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention related tools like 'mine_run_template' (for executing templates) or 'mine_query_builder' (for custom queries), leaving the agent to infer usage context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'including human disease models and annotations', which adds some context about return content, but does not disclose behavioral traits such as rate limits, authentication needs, or whether it's a read-only operation. The description is minimal and lacks crucial 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?
The description is a single, efficient sentence that front-loads the core purpose ('Get disease associations for a gene') and adds specific details ('including human disease models and annotations') without unnecessary words. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It specifies the type of associations returned, which helps, but lacks details on output format, error handling, or usage constraints. Without annotations or output schema, more context would improve completeness for effective agent 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 the schema fully documents the parameters ('gene_id' and 'limit'). The description does not add any meaning beyond what the schema provides, such as format examples for 'gene_id' or clarification on 'limit' behavior. Baseline 3 is appropriate as the schema handles parameter documentation.
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 specific action ('Get disease associations') and resource ('for a gene'), and distinguishes it from siblings by specifying the type of associations ('including human disease models and annotations'), unlike tools like 'get_gene_phenotypes' or 'search_diseases' which focus on different data aspects.
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 disease associations for a gene are needed, but does not explicitly state when to use this tool versus alternatives like 'search_diseases' or 'get_gene_phenotypes'. It provides basic context without exclusions or detailed guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it indicates this is a read operation ('Get'), it doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens with invalid gene IDs. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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?
Single sentence that efficiently conveys the tool's purpose with zero waste. Front-loaded with the main action and includes specific examples of what information is retrieved. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides adequate purpose but lacks completeness regarding behavioral aspects. Without annotations or output schema, it should ideally describe response format or error handling to be fully complete for agent 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 the schema already fully documents the single 'gene_id' parameter with examples. The description doesn't add any parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Get detailed information') and resource ('about a specific gene'), with specific details about what information is included ('symbol, name, location, species, and cross-references'). It distinguishes from siblings like 'get_gene_alleles' or 'get_gene_diseases' by being a general information retrieval tool rather than focused on specific aspects.
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 detailed gene information is needed, but doesn't explicitly state when to use this vs. alternatives like 'search_genes' or other gene-specific tools. It provides context but lacks explicit guidance on exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the tool runs queries and targets AllianceMine, it lacks critical behavioral details such as whether this is a read-only operation, what permissions are required, potential rate limits, error handling, or what the output format looks like. For a query execution tool with zero annotation coverage, this represents significant gaps in transparency.
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 with just two sentences that efficiently communicate the tool's purpose and target audience. Every word earns its place, with no redundant information or unnecessary elaboration. The structure is front-loaded with the core functionality followed by user guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing raw XML queries against a database system, the description is insufficiently complete. With no annotations, no output schema, and minimal behavioral disclosure, users lack critical information about what this tool actually returns, error conditions, performance characteristics, or security implications. The description should provide more context about the operation's nature and results.
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 fully documents the single 'xml' parameter. The description adds minimal value beyond the schema by mentioning 'PathQuery XML' in the context of the tool's purpose, but doesn't provide additional syntax examples, format requirements, or constraints beyond what's implied in the schema's description. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Run a raw PathQuery XML query') and target resource ('against AllianceMine'), distinguishing it from sibling tools like 'mine_natural_query' or 'mine_query_builder' that likely offer different query interfaces. It explicitly identifies the intended user group ('power users who know InterMine PathQuery syntax'), which further clarifies its specialized purpose.
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 provides explicit usage guidance by stating it's 'For power users who know InterMine PathQuery syntax,' which implicitly suggests when NOT to use it (for users unfamiliar with PathQuery syntax). It also distinguishes this tool from potential alternatives by specifying it handles 'raw PathQuery XML' queries, unlike sibling tools like 'mine_natural_query' or 'mine_search' that likely offer different query methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what the tool does (builds and runs queries) and provides an example, but doesn't disclose important behavioral traits like rate limits, authentication requirements, error handling, pagination behavior, or what happens with complex queries. The example helps but leaves operational details unspecified.
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 perfectly structured and concise. It starts with the core purpose, provides a detailed example that demonstrates multiple parameters in action, and ends with the supported operators list. Every sentence earns its place, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex query-building tool with 6 parameters, nested objects, and no output schema, the description is adequate but incomplete. The example query helps, but without annotations or output schema, it doesn't cover important aspects like response format, error conditions, performance characteristics, or how results are structured. The description does what it can but leaves significant gaps given 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?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds value by providing a concrete example query that demonstrates how parameters work together and lists supported operators for the 'where' clause, but doesn't add significant semantic meaning beyond what the schema provides. The baseline of 3 is appropriate given the comprehensive schema documentation.
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 with specific verbs ('Build and run structured queries') and resources ('against AllianceMine using a JSON DSL'). It distinguishes from sibling tools like 'mine_natural_query' (which likely uses natural language) and 'mine_search' (which might be simpler search) by emphasizing the structured JSON DSL approach.
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 this tool (for structured queries with JSON DSL) but doesn't explicitly state when NOT to use it or name specific alternatives. The example query and operator list give practical guidance, but there's no direct comparison to sibling tools like 'mine_natural_query' or 'mine_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool executes pre-built queries, requires parameter formatting (numeric keys, simple/full formats), and references a sibling tool (mine_list_templates) for discovery. However, it lacks details on error handling, performance, or output structure.
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: the first sentence states the core purpose, followed by parameter format details, examples, and a clear call-to-action for template discovery. Every sentence adds value without redundancy, making it efficient for an agent to parse.
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 (3 parameters, nested objects, no output schema, no annotations), the description is largely complete: it covers purpose, usage, parameter semantics, and references sibling tools. However, it lacks details on output format or error cases, which could be helpful for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema: it explains parameter format (numeric keys, simple vs. full), provides concrete examples (e.g., BRCA1, HGNC:1100), and lists common template names with usage context, enhancing understanding of how to structure params effectively.
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: 'Run a pre-built query template with parameters.' It specifies the action ('Run'), resource ('pre-built query template'), and distinguishes it from sibling tools like mine_list_templates (for discovery) and other gene-specific tools by focusing on template execution with parameterized queries.
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 provides explicit guidance on when to use this tool: for running templates discovered via mine_list_templates. It distinguishes it from alternatives by listing common templates (e.g., Gene_Orthologs vs. get_gene_info) and implies not to use it for direct queries (use mine_query or mine_natural_query instead).
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:

[![agr-mcp-server-js MCP server](https://glama.ai/mcp/servers/nuin/agr-mcp-server-js/badges/card.svg)](https://glama.ai/mcp/servers/nuin/agr-mcp-server-js)

Score Badge

Copy to your README.md:

[![agr-mcp-server-js MCP server](https://glama.ai/mcp/servers/nuin/agr-mcp-server-js/badges/score.svg)](https://glama.ai/mcp/servers/nuin/agr-mcp-server-js)

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/nuin/agr-mcp-server-js'

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