gnomAD MCP Server

by koido

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific genomic data types (ClinVar variants, copy number variants, genes, metadata, mitochondrial variants, regions, STRs, structural variants, general variants, liftover, gene search, variant search). The descriptions clearly differentiate what each tool retrieves, with no apparent overlap in functionality.
Naming Consistency4/5
Most tools follow a consistent 'get_*_info' or 'search_for_*' pattern, but there are minor deviations: 'get_copy_number_variant_info' uses 'variantId' while 'get_variant_info' uses 'variantId' (both camelCase), and 'get_structural_variant_info' uses 'variantId' while others use 'variant_id' (snake_case). The overall pattern is clear and readable despite these inconsistencies.
Tool Count5/5
12 tools is well-scoped for a genomic database API server covering multiple data types (variants, genes, regions, etc.) across different gnomAD versions. Each tool serves a specific purpose in retrieving different genomic entities, with no obvious redundancy.
Completeness4/5
The toolset provides comprehensive retrieval capabilities for the gnomAD domain, covering all major genomic data types with both specific lookup and search functionality. The only minor gap is the version compatibility limitations noted in tool descriptions (some tools only work with specific gnomAD versions), but agents can work around this by checking metadata or using alternative tools.
Average 3.1/5 across 12 of 12 tools scored.
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 status not available
This repository is licensed under Apache 2.0.
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 full burden. It states the tool retrieves metadata but doesn't disclose behavioral traits like whether it's read-only (implied by 'retrieve'), authentication needs, rate limits, error handling, or what the returned dict contains. The description is minimal and lacks context beyond the basic operation.
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 structured with clear sections for Args and Returns, making it easy to parse. However, it could be more front-loaded by starting with a more informative summary instead of the bracketed '[gnomAD API]'. The brevity is efficient but borders on under-specification.
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 has an output schema (returns a dict), the description doesn't need to detail return values. However, with no annotations, 2 parameters (one undocumented), and sibling tools that might overlap, the description is incomplete. It covers the basic operation but lacks context on usage, behavior, and full parameter semantics, making it minimally adequate.
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 documents the 'dataset' parameter with examples (gnomad_r4/gnomad_r3/gnomad_r2_1), which adds value, but it omits the 'reference_genome' parameter entirely. With 2 parameters and incomplete coverage, the description fails to fully explain parameter meanings beyond what the schema provides.
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 the tool retrieves metadata from the gnomAD API, which is a clear purpose. However, it doesn't specify what kind of metadata (e.g., dataset version info, sample counts, quality metrics) or distinguish it from sibling tools that retrieve specific data types like variant or gene information. The mention of 'v2/v3/v4' versions is helpful but 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 alternatives. The description doesn't mention prerequisites, such as needing a dataset ID, or differentiate it from sibling tools like get_variant_info or get_gene_info, which might retrieve overlapping metadata. Usage is implied only by the tool name and parameters.
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 mentions the API and dataset versions (v2/v3/v4) but lacks critical behavioral details such as authentication needs, rate limits, error handling, or what 'search results' entail beyond a dict return.
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 structured with sections for Args and Returns, but includes redundant information (e.g., repeating parameter names without added value). It's moderately concise but could be more front-loaded with essential usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained. However, with 3 parameters at 0% schema coverage and no annotations, the description provides only basic parameter hints and lacks completeness for effective tool use, such as examples or constraints.
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 lists parameters with brief notes (e.g., 'gnomAD dataset ID', 'Search string'), but these are minimal and don't fully explain semantics like valid dataset values or query formatting, leaving significant gaps.
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 resource ('genes'), and specifies the API context ('gnomAD API'). However, it doesn't explicitly differentiate from sibling tools like 'search_for_variants' or 'get_gene_info', 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?
No guidance on when to use this tool versus alternatives like 'search_for_variants' or 'get_gene_info' is provided. The description only lists parameters and returns without 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 full burden but provides minimal behavioral context. It mentions API version constraints ('v4 only') and build requirements ('GRCh38'), but doesn't disclose authentication needs, rate limits, error conditions, or what 'region info' contains beyond the return type. For a tool with 5 parameters and no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but has structural issues. The Args/Returns/Note sections are clear, but the opening line could be more front-loaded. The 'Note' about version support is important but could be integrated more smoothly. Some redundancy exists ('GRCh38' mentioned twice in parameter descriptions).
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 5 parameters with 0% schema coverage, no annotations, but with an output schema (which handles return values), the description is moderately complete. It covers most parameters and provides version constraints, but lacks behavioral context like authentication, rate limits, or error handling that would be important for API tool usage.
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 but only partially does. It explains 4 parameters (reference_genome, chrom, start, stop) with some constraints ('Build must be GRCh38'), but doesn't mention the 5th parameter 'dataset' with its default value 'gnomad_r4'. The description adds meaning for 4/5 parameters but leaves one completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve region information') and specifies the resource ('gnomAD API'), but doesn't explicitly differentiate from sibling tools like 'get_gene_info' or 'get_variant_info' which likely retrieve different types of genomic data. The 'v4 only' qualification adds specificity but not sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance through the 'v4 only' note and parameter constraints ('Build must be GRCh38'), suggesting when this tool is applicable. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_gene_info' for gene-level data or 'search_for_variants' for variant searches.
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 but provides minimal behavioral context. It states it's a retrieval operation but doesn't mention authentication requirements, rate limits, error conditions, or what specific information is returned beyond 'SV info'. The API source (gnomAD) is mentioned but without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement followed by Args and Returns sections. The description is appropriately sized with no redundant information. The front-loaded purpose statement is clear, though the parameter explanations could be more detailed given the 0% schema coverage.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter documentation and mentions the API source. The existence of an output schema reduces the need to detail return values. However, for a retrieval tool with multiple sibling alternatives, more context about when to use this specific tool would improve completeness.
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 0% schema description coverage, the description partially compensates by listing all three parameters with brief explanations. However, it doesn't provide format examples, valid values beyond basic types, or explain relationships between parameters (e.g., dataset must match reference genome). The parameter documentation is minimal but covers all required 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 tool's purpose: 'Retrieve structural variant info' with the specific resource (gnomAD API) and version scope (v2/v4). It distinguishes from siblings like 'get_variant_info' by specifying 'structural variant' type, but doesn't explicitly contrast with 'get_copy_number_variant_info' which might overlap.
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 on when to use this tool versus alternatives like 'get_variant_info' or 'get_copy_number_variant_info'. The description mentions dataset versions (v2/v4) but doesn't explain when to choose which version or how this differs from other variant retrieval tools in the sibling list.
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 this is a retrieval operation but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what specific variant information is returned. The mention of 'gnomAD API' hints at an external service but gives no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter and return details. It uses minimal sentences efficiently, though the Args/Returns formatting is slightly verbose. Every sentence adds value without redundancy.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter context but lacks behavioral and usage details. An output schema exists ('dict: variant info'), so return values needn't be explained. However, for a tool interacting with an external API and multiple sibling alternatives, more contextual guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds basic semantics by explaining each parameter's purpose (e.g., 'dataset' as gnomAD dataset ID, 'variantId' format example), but doesn't provide enums, constraints, or detailed formatting rules. This partially addresses the schema gap but leaves significant ambiguity.
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: 'Retrieve variant information' with specific API context ('gnomAD API') and version scope ('v2/v3/v4'). It distinguishes from siblings like 'get_clinvar_variant_info' and 'get_structural_variant_info' by focusing on general gnomAD variant data, but doesn't explicitly contrast 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. With many sibling tools available (e.g., 'get_clinvar_variant_info', 'get_structural_variant_info'), the description lacks any indication of appropriate contexts, prerequisites, or exclusions for this specific variant retrieval tool.
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 mentions the API version limitation (v2 only) and that it returns a dictionary, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what specific fields the returned dict contains. The description adds minimal value beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Note) and uses minimal space. The first sentence states the core purpose, followed by parameter details and important notes. However, the 'Args' and 'Returns' labels are somewhat redundant since this information is in structured fields.
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 4 parameters with 0% schema coverage and an output schema exists, the description provides basic parameter examples and return type but doesn't fully compensate for the missing schema documentation. It covers the version limitation but lacks details about authentication, error handling, or the structure of the returned dictionary. The existence of an output schema reduces but doesn't eliminate the need for behavioral context.
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 provides examples for source_variant_id and liftover_variant_id parameters, which helps understand format, but doesn't explain the reference_genome parameter (despite it being required) or the dataset parameter at all. The description mentions 'Args' and 'Returns' sections but leaves 2 of 4 parameters unexplained.
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 liftover information for variants, specifying it's for gnomAD API v2 only. It distinguishes from siblings by focusing on variant coordinate conversion rather than variant annotation, gene info, or searches. However, it doesn't explicitly contrast with the most similar sibling 'get_variant_info' which might also handle variants.
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 by specifying 'v2 only' and 'Not supported in v3/v4', providing some context about when NOT to use it. However, it doesn't explicitly state when to choose this tool over alternatives like 'get_variant_info' or provide guidance on parameter combinations (e.g., when to use source_variant_id vs liftover_variant_id).
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 mentions the API and returns a dict with variant_id, but lacks details on behavioral traits like rate limits, authentication needs, error handling, pagination, or what the search results include beyond variant_id. This is inadequate for a search 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 appropriately sized and front-loaded, starting with the core purpose. The Args/Returns structure is clear, but the bracketed '[gnomAD API]' could be integrated more smoothly, and it's slightly verbose in listing dataset examples.
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 3 parameters with 0% schema coverage and an output schema exists (returns dict), the description is moderately complete. It explains parameters well but lacks behavioral context and usage guidelines. The output schema handles return values, so no need to detail them further, but overall it's adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: dataset as gnomAD dataset ID with examples, reference_genome as genome type with examples, and query as a search string for variant_id. This clarifies semantics beyond the bare schema, though it could provide more context on valid values or search syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for variants using the gnomAD API, specifying it works with v2/v3/v4 datasets. It distinguishes from siblings like 'search_for_genes' by focusing on variants, though it doesn't explicitly differentiate from 'get_variant_info' which might retrieve specific variant details rather than search.
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. For example, it doesn't clarify if this should be used for broad searches versus 'get_variant_info' for detailed info on known variants, or how it relates to other variant-related tools like 'get_clinvar_variant_info'.
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 the tool retrieves information (implying read-only), but doesn't cover error handling, rate limits, authentication needs, or what happens with invalid inputs. The return type is mentioned but without detail on structure or potential null responses.
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 efficiently structured with a clear purpose statement followed by parameter and return sections. Every sentence adds value: the first establishes context and scope, while the subsequent lines document inputs and outputs without redundancy.
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 (3 required parameters, no annotations, but with an output schema), the description is partially complete. It covers parameters and return type at a high level, but lacks behavioral details like error cases or usage examples. The output schema existence reduces the need to fully describe returns, but more operational context would help.
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 description explicitly lists all three parameters with brief explanations, compensating for the 0% schema description coverage. It clarifies that 'dataset' corresponds to gnomAD versions, 'reference_genome' specifies GRCh37/GRCh38, and 'variant_id' identifies the variant, adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Retrieve ClinVar variant info' with specific API context (gnomAD API) and version coverage (v2/v3/v4). It distinguishes itself from siblings like 'get_variant_info' by focusing specifically on ClinVar data, though it doesn't explicitly contrast with all similar tools.
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. While the description implies it's for ClinVar-specific variant data, it doesn't explain when to choose this over 'get_variant_info' or other variant-related tools, nor does it mention prerequisites or constraints.
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 API source (gnomAD) and version constraints (v4 only), which adds some context. However, it lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what specific info is returned (e.g., fields in the dict). For a tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The use of sections (Args, Returns, Note) adds structure, but the note could be integrated more smoothly. There's minimal waste, though it could be slightly more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and an output schema present, the description is moderately complete. It covers the purpose and some parameter semantics but lacks behavioral details and full parameter explanations. The output schema handles return values, so that gap is mitigated, but overall completeness is adequate with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides examples for variantId (e.g., '18714__DUP') and specifies reference_genome as 'GRCh38,' adding meaning beyond the bare schema. However, it doesn't mention the dataset parameter or explain its purpose, leaving one of three parameters undocumented. This partial compensation results in a baseline score.
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 copy number variant info from the gnomAD API, specifying it's for v4 only. It distinguishes itself from siblings by focusing on CNVs rather than other variant types like ClinVar, mitochondrial, structural, or general variants. However, it doesn't explicitly contrast with get_structural_variant_info, which might be a close sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'v4 only' and noting 'Not supported in v2/v3,' which provides some context on when to use it. However, it doesn't explicitly state when to choose this tool over alternatives like get_structural_variant_info or get_variant_info, nor does it mention prerequisites or exclusions beyond version compatibility.
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 version constraints (v4 only) and an alternative tool, but lacks critical behavioral details: authentication requirements, rate limits, error handling, pagination, or what specific 'gene info' includes. The description doesn't contradict annotations (none provided), but is insufficient for a tool with 4 parameters and 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 well-structured with clear sections (Args, Returns, Note) and front-loaded the core purpose. It's concise with no wasted sentences, though the parameter documentation could be more efficiently integrated rather than listed separately.
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 4 parameters with 0% schema coverage and no annotations, the description is moderately complete: it covers the tool's purpose, version constraints, and two parameters. However, it lacks details on the other two parameters, behavioral traits, and while an output schema exists, the description doesn't hint at the structure of returned 'gene info'. For a retrieval tool with sibling alternatives, more guidance would be helpful.
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 only documents 2 of 4 parameters (gene_id, gene_symbol) with examples, but omits 'dataset' and 'reference_genome' entirely. The description adds some value with examples for the two gene parameters, but fails to cover half the parameters, leaving significant gaps.
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: 'Retrieve gene information (v4 only)'. It specifies the verb ('Retrieve') and resource ('gene information'), and distinguishes it from v2/v3 versions. However, it doesn't explicitly differentiate from sibling tools like 'search_for_genes' beyond version compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'v4 only' and 'Not supported in v2/v3. Use search_for_genes instead.' It explicitly names an alternative tool for other versions. However, it doesn't specify when to use this vs. other sibling tools like 'get_region_info' or clarify if both gene_id and gene_symbol can be provided simultaneously.
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 the API source and version constraints, but lacks details on authentication needs, rate limits, error handling, or what the 'STR info' dict typically contains (e.g., fields like allele frequencies). For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Note) and front-loaded the core purpose. It's concise with no wasted words, though the omission of the 'dataset' parameter slightly affects completeness. Every sentence adds value, such as the version warning and parameter examples.
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 (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and key parameters but misses details on the undocumented 'dataset' param and behavioral aspects like auth or errors. The output schema exists, so describing return values isn't needed, but other gaps remain for adequate 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 0%, so the description must compensate. It documents two parameters ('reference_genome' and 'id') with examples and notes, adding meaning beyond the bare schema. However, it omits the third parameter 'dataset' entirely, which has a default value 'gnomad_r4'—this gap reduces effectiveness. The description provides partial but incomplete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve STR info' from the gnomAD API, specifying it's for 'v4 only'. It distinguishes from siblings by focusing on STR (short tandem repeat) data, unlike gene/variant tools. However, it doesn't explicitly contrast with all siblings (e.g., 'get_region_info' might overlap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context via the 'Note' about version support ('Not supported in v2/v3'), implying when not to use it. It doesn't explicitly guide when to choose this over similar tools (e.g., 'get_region_info' for broader genomic regions) or mention prerequisites like API access. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: API source (gnomAD), version constraints (v4 only, not v2/v3), and variant ID format requirements. However, it lacks details on permissions, rate limits, error handling, or response structure beyond 'dict: mito variant info'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by Args, Returns, and Note sections. Every sentence adds value: the first states purpose and constraints, Args clarify parameters, Returns indicates output type, and Note provides critical exclusion. Zero waste.
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 3 parameters with 0% schema coverage and an output schema present, the description is fairly complete. It covers purpose, usage constraints, and parameter semantics adequately. However, as a data retrieval tool with no annotations, it could benefit from more behavioral context (e.g., authentication, rate limits) to reach full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for two parameters: 'reference_genome' (specifies GRCh37 or GRCh38) and 'variant_id' (explains format 'M-8602-T-C' and build requirement GRCh38). The third parameter 'dataset' is undocumented in both schema and description, but the description's 'v4 only' note partially covers it. This is strong compensation for low 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: 'Retrieve mitochondrial variant info' with the specific scope '[gnomAD API]' and 'v4 only'. It distinguishes from siblings by focusing on mitochondrial variants, unlike other tools for ClinVar, copy number, or general variants. However, it doesn't explicitly contrast with 'get_variant_info' which might handle non-mitochondrial variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it: for mitochondrial variants in gnomAD v4, with explicit exclusions ('Not supported in v2/v3'). It implies usage by specifying the variant ID format and reference genome build. However, it doesn't name alternatives among siblings or detail when to choose this over other variant tools.
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:

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

Score Badge

Copy to your README.md:

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

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