MyGene MCP Server

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation2/5
There are overlapping tools like query_homologous_genes and get_gene_orthologs, which both find cross-species homologs. Additionally, query_with_filters, build_complex_query, and search_by_field all appear to serve similar flexible querying purposes, causing confusion.
Naming Consistency3/5
Most tools follow a consistent get_gene_* or query_genes_by_* pattern, but there are deviations such as query_with_filters, build_complex_query, search_by_field, and export_gene_list that break the convention. The mixing of verbs like query, search, and build adds inconsistency.
Tool Count2/5
With 26 tools, the server exceeds the recommended range and feels heavy, even for a comprehensive gene API. While each tool may target a specific aspect, the sheer number makes it harder for agents to select the appropriate one.
Completeness4/5
The tool set covers a wide range of gene-related queries including diseases, chemicals, pathways, GO terms, expression, variants, and orthologs, with batch operations and export functionality. Minor redundancies exist but no obvious gaps for the MyGene.info domain.
Average 2.7/5 across 26 of 26 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It only says 'get', implying a read, but gives no information about aggregation, pagination, output structure, or any side effects. The behavior is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single generic sentence that adds no value; this is under-specification, not conciseness. The sentence does not earn its place because it communicates nothing beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and a likely output schema, the description is woefully incomplete. It gives no indication of the domain, the type of statistics, or how the parameters affect results. An agent cannot confidently invoke this tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention 'size', 'species', or clarify the meaning of 'field'. A parameter-heavy tool with three parameters and zero semantic guidance is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get statistics for a specific field' essentially restates the tool name without adding specificity. It fails to indicate what kind of field or statistics, or how it relates to the gene-centric sibling tools. This is a near-tautology, not a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_available_fields or search_by_field. The description provides no context, prerequisites, or exclusions, leaving the agent without any decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only mentions 'export' without disclosing output behavior, file formats, side effects, or permissions. This lack of transparency makes it impossible for an agent to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified. It does not provide enough information to be considered appropriately sized; it is more of a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, zero description coverage, and multiple parameters, the description is grossly inadequate. It does not explain the concept of exporting, available formats, or how the output is structured, even though an output schema exists. This tool would be nearly impossible to invoke correctly based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters, but schema description coverage is 0% and the tool description does not explain any of them. The parameter names (fields, format, gene_ids) are self-explanatory to some extent, but the description adds no meaning beyond the schema, especially for 'fields' and 'format'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Export gene data') but is vague about what 'export' means and what 'various formats' includes. It does not distinguish from sibling tools such as get_genes_batch or query_genes, which also handle gene data.
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 about when to use this tool versus alternatives. The description gives no context for when exporting is appropriate or what differentiates it from querying or batch retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the query is read-only, how filters interact (AND/OR), what result format to expect, or any limits or side effects. This is a significant gap for a tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is under-specified for a tool with 9 parameters. While it is short, it does not earn its place because it restates the name without adding useful information. Appropriate structure would provide a clear purpose statement and filter rationale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is woefully incomplete given the tool's complexity. It does not explain the query scope, how filters are combined, default behavior, or any usage caveats. An agent would have no idea how to construct a proper query or interpret results beyond raw parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither the schema nor the description explains any of the 9 parameters. The description does not mention parameter names, types, or semantics. For example, 'q' and 'size' are not defined, and filter behaviors for taxid, chromosome, etc., are unspecified. The description adds no value beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query with multiple filters applied' is essentially a restatement of the tool name 'query_with_filters'. It fails to specify what entity is being queried (e.g., genes, homologs) or what the filters operate on, providing no meaningful differentiation from sibling tools like query_genes or query_genes_by_interval.
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 does not mention that this is for filtered queries or that simpler tools like query_genes should be used when no filters are needed. There is no exclusionary or alternative context provided.
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, the description carries the full burden of behavioral disclosure, but it only states that GO annotations are retrieved. It does not disclose required inputs, filtering behavior, or return format, leaving the agent with minimal understanding of side effects or prerequisites.
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 sentence with no redundancy, making it concise and front-loaded. However, the brevity borders on under-specification rather than efficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this tool has 3 parameters, no schema descriptions, and no annotations, a one-sentence description is severely inadequate. The presence of an output schema does not compensate for the lack of parameter explanations and usage context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost no parameter guidance. It mentions 'evidence codes' which loosely maps to the 'evidence_codes' parameter but does not explain 'gene_id' or 'aspect', leaving all parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('GO annotations with evidence codes'), which clearly distinguishes it from siblings like 'get_gene_annotation' (singular) and 'query_genes_by_go_term'. However, the phrase 'with evidence codes' is ambiguous—it could mean the response includes evidence codes or filters by them.
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. The sibling list offers related tools (e.g., 'get_gene_annotation', 'query_genes_by_go_term'), but the description does not mention any exclusions or selection criteria.
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 only states that it retrieves pathways, but gives no details about how the 'sources' parameter affects behavior, potential error conditions, or the nature of the returned data. This is insufficient for a tool with a non-trivial optional filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise. However, it is under-specified to the point of being minimally informative, which is not ideal conciseness—it's more like an omission of needed content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema is present, the description omits crucial context about the optional 'sources' parameter and does not clarify the relationship to sibling tools. For a tool with only two parameters, this brevity leaves significant gaps in understanding when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for its parameters, and the tool description does not explain the meaning of 'gene_id' or 'sources'. The word 'gene' vaguely maps to 'gene_id', but 'sources' is completely unaddressed, leaving the agent without any semantic grounding for the 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 'Get all pathways for a gene' clearly states the action (get) and resource (pathways for a gene), making the tool's purpose obvious. However, it doesn't explicitly distinguish itself from the sibling 'query_genes_by_pathway', which reverses the query direction, 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?
There is no guidance on when to use this tool versus alternatives like 'query_genes_by_pathway' or other gene-related tools. The description provides no context for selecting this tool over others, so it fails to offer usage criteria.
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, the description must disclose behavioral details, but it only says 'Search for genes' — implying a read operation without stating pagination, rate limits, return format, or any special behavior of the MyGene.info API. The mention of the API name provides minor context but no actionable transparency about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically simple sentence with no wasted words, making it easy to parse. However, it is under-specified for a tool with 10 parameters and numerous siblings; conciseness here is due to brevity rather than well-structured, high-information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: 10 parameters, no annotations, and an output schema that is present but not described. The description provides almost no operational context—no query construction examples, no parameter semantics, no mention of default behavior or how to filter by species. It is inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameter meanings, but it mentions none of the 10 parameters. 'q', 'species', 'fields', and 'fetch_all' all remain undefined in the description, leaving the agent to infer semantics solely from the bare schema. This is a complete failure to compensate for missing 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 states a clear action: 'Search for genes' using the MyGene.info query API. It identifies the resource (genes) and the operation (search), making the primary purpose evident. However, it does not differentiate from the many sibling query tools, such as query_genes_batch or query_with_filters.
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. Given the large set of sibling tools (query_genes_batch, query_genes_by_disease, search_by_field, etc.), the description should explain that this is the general-purpose gene search endpoint or indicate specific scenarios. It simply states what it does, leaving usage decisions entirely to the agent.
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, the description must carry the burden of behavioral transparency. It only says 'search,' implying read-only behavior, but does not disclose permissions, rate limits, pagination, or other operational details. The safer read-only nature is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. While it is under-specified, that is a completeness issue; the writing itself is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, a nested object, and no annotations, this description is critically incomplete. It does not explain the structure of field_queries, allowable field names, how boolean operators are applied, or the effect of default values. The output schema is present but the input contract remains largely mysterious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description should compensate. It only hints at two parameters (fields and boolean operators) but fails to explain the structure of field_queries, the meaning of operator values, or the role of size, species, and fields. This is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool searches by specific fields using boolean operators, which gives a clear verb and resource. However, it does not specify the data domain (e.g., genes, diseases) or differentiate it from sibling search tools like query_with_filters or build_complex_query, making it somewhat vague.
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 other search tools. It neither names alternatives nor describes the recommended context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must fully disclose behavioral traits, but it only states the basic function. It does not mention return behavior, filtering, side effects, or any other operational characteristics, offering insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant wording, achieving high efficiency. However, it lacks any additional structure or detail, making it appropriately concise but perhaps too sparse for the tool's complexity.
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?
The tool has three parameters, no annotations, and no parameter descriptions, yet the description only provides a high-level summary. It does not explain how to use the parameters or what output to expect, though an output schema is present. This is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for its three parameters. The description says 'across species', which loosely implies the 'target_species' parameter, but it does not explain 'sources' or the relationship between parameters. This minimal compensation does not adequately cover the missing semantic information.
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 'orthologs across species', indicating a read operation to retrieve orthologous genes across species. However, it does not explicitly distinguish from the sibling tool 'query_homologous_genes', which could be similar, so it is not fully differentiated.
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 'query_homologous_genes' or 'query_genes'. It does not mention any exclusions, prerequisites, or context, leaving the agent without direction 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action without revealing important traits like required email for NCBI, handling of invalid IDs, return format, or rate limits. The minimal 'Get' implies a read operation but offers no substantive behavior beyond that.
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 unnecessary words. It front-loads the core action and object, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no annotation or schema descriptions, this one-sentence description is grossly inadequate. It does not explain how to construct a request, what fields/filter/species do, or what the output schema contains. The presence of an output schema does not excuse the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate. It only references 'multiple genes' (which maps to gene_ids) but ignores email, fields, filter_, species, and dotfield. The description adds no meaning to the parameters beyond what the schema's type structure already shows.
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 retrieves annotations for multiple genes, using a specific verb ('Get') and resource ('annotations for multiple genes'). It distinguishes itself from singular tools like get_gene_annotation by emphasizing 'multiple genes' and 'single request', but it does not explicitly differentiate from similar batch tools like query_genes_batch.
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 does not mention use cases, exclusions, or alternative tools, leaving the agent without direction on when to select this over 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?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'find genes associated with diseases,' implying a read operation, but does not mention default parameters (size=10, species='human'), how 'source' is used, or that disease_id and disease_name are alternative identifiers. This leaves key behaviors undisclosed.
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 concise sentence with no redundant wording, making it easy to parse. It lacks fluff, and the structure is clear, though the minimal content contributes to under-specification in other dimensions.
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?
Despite having an output schema, the description is incomplete for a tool with five optional parameters and no annotations. It does not explain that a disease identifier is likely needed, how filtering works, or what 'associated' means in terms of evidence or confidence. The text gives insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the five parameters (size, source, species, disease_id, disease_name). Since schema description coverage is 0%, the description fails to compensate by explaining parameter roles, defaults, or relationships, making it impossible for an agent to understand parameter semantics from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'finds genes associated with diseases,' identifying the verb and resource. However, it does not differentiate from the similarly named sibling 'get_gene_disease_associations,' and lacks detail on query modes (e.g., by disease name or ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_gene_disease_associations' or 'query_genes_by_chemical.' There are no prerequisites, exclusions, or examples, leaving the agent to guess the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states a generic query action. It does not mention that the tool accepts optional filters, what it returns, or any limitations, paging behavior, or data source specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which aids clarity. However, it is under-specified to the point of being generic, offering little structural detail that would help an agent understand the tool's capabilities.
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?
The tool has six optional parameters, no annotations, and no schema-level descriptions, yet the description gives no context about query semantics or how to construct an expression-based query. The presence of an output schema reduces the need to describe return values, but the core functionality remains opaque, especially given the overlapping sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the six parameters, but it only mentions expression patterns generically. Parameter names like tissue and species are self-explanatory, but expression_level and size are not explained, and the description adds no detail about how these parameters interact.
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 'Query genes by expression patterns' uses a specific verb and resource, and the phrase 'by expression patterns' differentiates it from siblings like query_genes_by_disease and query_genes_by_pathway. However, it does not elaborate on what constitutes an 'expression pattern' or how it scopes results.
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 get_gene_expression_profile or query_genes_by_disease. There are no exclusions, prerequisites, or comparisons to sibling tools, leaving usage to be inferred solely from the name.
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 disclosing behavioral traits. It only says 'find', implying a read-only operation, but does not mention any specific behaviors such as whether it supports multiple homology types, the effect of the 'size' parameter, or any potential limitations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the core action. However, it is arguably under-specified, which slightly reduces the structural quality, but for conciseness alone it earns a high score.
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?
Despite having an output schema, the description is too thin to be contextually complete. It lacks essential information about when to choose this tool over siblings, does not explain the 'homology_type' parameter or its default, and provides no behavioral context. The tool has 4 parameters and meaningful complexity, so a more detailed description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description fails to add any meaning to the parameters. It does not mention 'gene_symbol', 'species_list', 'size', or 'homology_type', nor does it explain what these parameters do. The description is entirely disconnected from the parameter schema, providing no semantic bridge for the agent.
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 'Find homologous genes across species' clearly states the tool's purpose with a specific verb ('find') and resource ('homologous genes'). It is understandable but does not differentiate from the sibling tool 'get_gene_orthologs', which likely has overlapping functionality.
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 'get_gene_orthologs' or 'query_genes'. It does not mention contextual scenarios, exclusions, or prerequisites, leaving the agent to infer usage from the tool 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only says 'Get detailed annotation' without explaining what 'detailed' includes, how results are structured, what happens with default parameters like dotfield, or whether certain species are supported. This adds minimal value beyond the tool name.
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, front-loaded sentence with no unnecessary words. It is easy to scan and understand at a glance, though it lacks informative detail. This is appropriately concise but not fully specified.
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 tool with 4 parameters and many sibling annotations, the description is severely under-specified. It does not explain the general versus specialized nature, parameter semantics, or selection criteria. The presence of an output schema covers return values, but the description still fails to provide enough context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 4 parameters. It only implicitly covers gene_id via 'by ID', leaving fields, species, and dotfield entirely unexplained. No meaning is added to these parameters, which are not self-explanatory (especially dotfield).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Get' and the resource 'detailed annotation for a specific gene by ID', clearly indicating what the tool does. However, it does not distinguish this general annotation tool from specialized siblings like get_gene_go_annotations or get_gene_pathways, making the scope somewhat ambiguous.
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 such as get_gene_go_annotations or get_gene_pathways. There is no mention of preferred use cases, prerequisites, or exclusions. The description solely states what it does without contextualizing its place among the 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 must carry full behavioral disclosure. It mentions the data source (ClinVar and other sources), which adds some context, but fails to disclose potential side effects, read-only nature, pagination, or any other behavioral traits. It is not misleading, but it is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and readable. However, it is under-specified for a tool with three parameters and a rich context, so it sacrifices usefulness for brevity. It is not overly verbose but fails to include critical parameter details.
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?
The tool has an output schema, so return values are likely covered there. However, the description does not explain what 'variants' are, what filters (variant_type, clinical_significance) can be applied, or what 'other sources' are. It is incomplete for a tool embedded in a large family of query functions, lacking distinction from and relation to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention or explain any of the three parameters (gene_id, variant_type, clinical_significance). The agent is left without any semantic guidance beyond the bare schema, which lists no descriptions or enums.
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), the resource (variants), and the data source (ClinVar and other sources). This is a specific verb+resource combination that is distinct from any sibling tool, which all focus on other biological entities and relationships.
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 query tools, the lack of explicit context or exclusions makes it unclear whether this is the right tool for a given task beyond the implied purpose of retrieving variants.
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, the description carries the full burden for behavioral disclosure, but it only states the core function. It omits details about default species, result limits, or the relationship between chemical_id and chemical_name.
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 concise sentence with no fluff, front-loading the main action. However, it may be too terse to cover important context, but that is a completeness issue.
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 tool with 5 parameters, no annotations, and an output schema, the description is insufficient. It doesn't explain return values, interactions between parameters, or how to filter by species/chemical. The presence of a closely named sibling adds to the 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?
Schema coverage is 0% and the description adds no parameter explanations. While parameter names like chemical_id and interaction_type are self-explanatory to some extent, the description does not clarify expected formats, allowed values, or how parameters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' with a clear object 'genes that interact with chemicals/drugs', which conveys the core functionality. However, it does not differentiate from the sibling tool 'get_gene_chemical_interactions', which likely performs a similar function.
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 like 'get_gene_chemical_interactions' or 'query_genes_by_disease'. The description is purely functional with no usage 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 must carry the full burden of behavioral disclosure. It hints at 'evidence filtering' but does not explain defaults, return format, pagination, or any side effects. For a query tool with multiple filters, this is an insufficient level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose. While it is sparse, the brevity is not a structural issue, and it reads as a clean, concise statement.
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?
With 7 parameters, no annotations, and zero parameter documentation, the one-line description is not sufficient for an agent to correctly select and invoke the tool. The presence of an output schema helps with return values, but input semantics and filtering behavior remain too vague for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references go_id/go_name via 'GO terms' and evidence_codes via 'evidence filtering'. It provides no clarification for size, aspect, qualifier, or species, nor their defaults. This does not adequately compensate for the lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Query' plus resource 'genes by GO terms', making the core function clear. The mention of 'evidence filtering' adds a distinguishing behavior beyond the generic name. However, it does not explicitly differentiate from similarly named siblings like get_gene_go_annotations, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_gene_go_annotations, query_genes, or query_genes_by_expression. It neither states preferred use cases nor when to avoid the tool. The description only restates what the tool does, without contextual direction.
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 does not state whether this is a read-only operation, any side effects, required permissions, or what the output structure is. The verb 'build' is ambiguous about whether it constructs a query or executes 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 a single sentence with no filler words. Every word contributes to the core meaning, and it is front-loaded with the primary action ('Build complex boolean queries').
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 has 6 optional parameters and no parameter descriptions, the one-sentence description is insufficient to guide construction of a valid query. The output schema exists but does not clarify input semantics or relationship between clauses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions filters and aggregations but does not explain the boolean clauses (must, should, must_not) or the size parameter. The parameter names are conventional but not self-explanatory without further context.
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 builds complex boolean queries and mentions filters and aggregations, distinguishing it from simpler query tools like query_with_filters. However, it does not explicitly specify what data is being queried, relying on sibling tool context to imply the gene 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?
There is no guidance on when to use this tool versus alternatives such as query_with_filters or query_genes. The description lacks context for scenario-based selection 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'get', implying a read-only operation, but does not detail any limitations, output structure, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately minimal, though perhaps too minimal for completeness.
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, zero parameter coverage, and the presence of an output schema, the description remains too sparse to provide adequate context. It does not mention the output schema or any usage specifics, making it insufficient for a tool with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no direct explanation of parameters. The phrase 'across tissues/cell types' hints at the datasets parameter but does not clarify its format or purpose.
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 retrieves an expression profile across tissues/cell types, using a specific verb and resource. It is understandable, though it does not explicitly distinguish itself from sibling tools like query_genes_by_expression.
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. There is no mention of context, exclusions, or related 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?
With no annotations provided, the description carries the full burden. It only states that it queries multiple genes, which implies a read operation, but does not disclose return format, pagination, rate limits, or any operational nuances. Minimal behavioral context beyond the implied read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the key point. While concise, it is arguably too terse to be fully useful, but it earns points for zero wasted words.
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 has six parameters, no annotations, and an output schema, the description is severely incomplete. It does not mention the output, parameter usage, or any guidance for a complex batch query tool. Even though an output schema exists, the description should hint at what data is returned or how the batching works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the six parameters. The schema itself provides only type/defaults, not semantic meaning. The description fails to compensate for the complete lack of 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 tool queries multiple genes in a single request, distinguishing it from single-gene or disease/pathway-specific query tools. The verb 'Query' and resource 'genes' are specific, and the scope is explicitly defined as batch/multiple.
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 like query_genes or get_genes_batch. It does not mention prerequisites, 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?
With no annotations, the description carries the full burden, but it only says 'Find genes...' without discussing prerequisites (e.g., requiring a pathway ID or name), filtering behavior, or output details. It does not mislead but is severely under-informative.
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, clear sentence with no irrelevant words. It is front-loaded and efficient, but the brevity comes at the cost of completeness, earning a still respectable score.
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 five optional parameters, no annotations, and only an output schema, the description is far too sparse. It does not explain how to form a query, what filters are available, or any behavior expectations, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the five parameters, and since schema descriptions are absent, the agent has no help interpreting fields like 'size' or 'source'. It adds no value beyond what the parameter names already suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Find genes') and the resource ('in specific pathways'), which distinguishes it from sibling tools like query_genes_by_disease or query_genes_by_chemical. However, it could be more specific about how pathways are identified (e.g., by ID or name).
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 use when a pathway is of interest, which is a loose usage guideline. But it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer the context from the tool name.
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, the description carries full responsibility for behavioral disclosure. It merely says 'Get' without explaining potential filtering via 'sources', pagination, or any constraints. The behavior of the optional 'sources' parameter is entirely undisclosed.
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 concise sentence with no unnecessary words. It is front-loaded and immediately communicates the core 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?
Although an output schema exists, so return values are covered, the description lacks critical context about the 'sources' parameter and how it modifies interactions. With two parameters and no annotations, this minimal description under-specifies the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'gene_id' or 'sources' parameters. While 'for a gene' implies the role of gene_id, it adds no meaning beyond the schema. The 'sources' parameter is completely undocumented, leaving users without any 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 uses a specific verb and resource: 'Get chemical/drug interactions for a gene.' This clearly distinguishes it from sibling tools like get_gene_disease_associations or get_gene_variants, which target different data types.
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 such as query_genes_by_chemical or other gene-specific tools. There are no contextual hints, exclusions, or references to 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 must carry behavioral disclosure. It only states the basic function and does not mention any behavioral traits such as read-only status, permission requirements, pagination, or return format. This is a significant gap for a read-like 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 sentence with zero fluff, front-loading the essential action and resource. Every word is functional, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse to be fully contextual. It omits explanation of the 'sources' parameter, provides no usage context, and does not give any indication of what data sources are available or how results are scoped. For a 2-parameter tool, this is inadequate for confident tool selection and invocation.
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 0% schema coverage, the description should compensate for parameter documentation. The phrase 'for a gene' implies the role of gene_id, but the 'sources' parameter is completely ignored. No additional meaning or format details are provided, leaving ambiguity about how to use the optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get disease associations for a gene' clearly states the action (get) and resource (disease associations for a gene). It is specific and distinguishes this tool from the sibling 'query_genes_by_disease', which performs the inverse direction.
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 the inverse sibling 'query_genes_by_disease' or any exclusion criteria, 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?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic query action and does not mention pagination (size), default fields, species handling, or any limits or side effects, leaving the agent without important operational 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, front-loaded sentence with no filler. Every word contributes to conveying the core purpose, making it highly concise and easy to parse.
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?
With 6 parameters and no annotations, the description is too sparse to fully guide invocation. It omits defaults, pagination, and field selection details, though an output schema is present, so return values are partially covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that start/end are chromosome positions, but it does not explain the semantics of optional parameters like size, fields, or species, even though they have defaults and meaningful behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('genes') with a clear scope ('by genomic interval (chromosome position)'). It clearly distinguishes this tool from sibling tools like query_genes_by_disease or query_genes_by_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when querying genes by a chromosome interval. However, there is no explicit guidance about when not to use it or which alternative should be used for other query types, despite many sibling query tools existing.
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, the description carries the full burden. It only states that a list is returned, without disclosing any behavioral traits such as read-only nature, caching, or error behavior. Minimal 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, clear sentence that is front-loaded with the action verb. It is concise and contains 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?
For a simple no-parameter tool with an output schema, the description is essentially complete: it states what is returned. It could potentially mention context about how the returned fields are used, but given the low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms an empty object. With no parameters to describe, the baseline is 4. The description adds no parameter info, which is acceptable.
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: to retrieve a list of all available fields in MyGene.info. The verb 'Get' and the specific resource 'all available fields' make it unambiguous and distinguish it from sibling tools like get_field_statistics.
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 one needs to know available fields, but provides no explicit guidance on when to use vs alternatives. There is no mention of exclusions or contextual triggers beyond the basic purpose.
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 must carry full behavioral disclosure. It only says 'Get metadata', which implies a read-only operation, but it does not describe what metadata is returned, any limitations, or potential side effects. This is minimal.
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, concise sentence with no extraneous information. It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple (no parameters) and an output schema exists, so the description need not explain return values. It is sufficient for an agent to understand this is a metadata endpoint, though a bit more detail about the kind of metadata could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. Per the rubric baseline, this scores 4. The description does not need to explain parameters because there are none, and it adds no confusion.
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 'Get' and the resource 'metadata about the MyGene.info API service'. It distinguishes from sibling tools by indicating this is service-level metadata, not gene or disease querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: use this tool to obtain API service metadata. However, there is no explicit guidance on when to choose this over alternatives, and no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool 'Get[s] a list', implying a safe read operation, and 'all supported species' suggests no filtering or pagination. It does not discuss side effects, authentication, or response formatting, but for such a simple tool, this is adequate without contradicting anything.
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?
A single sentence that delivers the complete purpose with no redundant words. Every word earns its place, and the structure is front-loaded with the verb and resource.
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 is extremely simple (zero parameters, no nested objects) and an output schema exists, so the description does not need to explain return values. The one-line description fully covers the tool's purpose and scope. No further context is needed given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (vacuously). The baseline for 0 params is 4. The description adds no parameter-level detail because none exist, which 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 the function: 'Get a list of all supported species in MyGene.info.' The verb 'Get' combined with the specific resource ('list of all supported species') leaves no ambiguity, and it is distinct from siblings like query_genes or get_available_fields, which serve different purposes.
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: call this tool when you need the complete list of supported species. However, it provides no explicit guidance on when to prefer this over alternatives, nor does it mention any exclusions or prerequisites. Minimal but acceptable for a zero-parameter utility.
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:

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

Score Badge

Copy to your README.md:

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

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