Skip to main content
Glama

fetch_clinvar_vcf

Read-only

Read one region of ClinVar's monthly release VCF, as the VCF ClinVar publishes: its header, then every record overlapping the region, through the release's tabix index so only those blocks are fetched. The ID column is the ClinVar Variation ID and INFO carries ClinVar's own CLNSIG, CLNREVSTAT and CLNDN. Use it to put ClinVar's calls for a locus beside your own.

Input Schema

NameRequiredDescriptionDefault
endYeslast base of the region (1-based, inclusive).
chromYesthe chromosome, with or without its chr prefix.
startYesfirst base of the region (1-based).
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
assemblyNowhich release VCF to read.GRCh38
max_recordsNocap on records returned; the result says when the region held more.

Output Schema

NameRequiredDescriptionDefault
vcfYesClinVar's header and the region's records, as the file holds them
recordsYeshow many records the region returned
summaryYeswhich release was read, and how many records the region held
fileDateYesthe release's own ##fileDate, which names the release read
endpointsYesthe VCF and index URLs actually read
truncatedYeswhether the region held more records than max_records

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral detail beyond the read-only annotations: it explains that the output is a VCF with header and overlapping records, that fetching uses the tabix index, and what the ID and INFO columns contain. It does not discuss truncation behavior, errors, or data-size limits, but the key output semantics are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three dense, front-loaded sentences with no filler. It moves from what is read, to what the output contains, to the intended use.

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 read-only fetch tool with annotations, a rich 7-parameter schema, and an output schema, the description covers the essential behavior and output content. It omits explicit mention of assembly selection, max_records truncation, and the project-file parameters, but those are documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter meanings are already fully documented in the schema. The description reinforces the region-based nature of chrom/start/end but adds no new syntax or constraints beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: reading one region of ClinVar's monthly release VCF. It also identifies the exact payload, including the VCF header, overlapping records, the Variation ID column, and ClinVar INFO fields, which clearly distinguishes it from generic variant lookup tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: putting ClinVar's calls for a locus beside your own data. However, it does not explicitly name alternatives such as lookup_variant or read_variant_calls, nor does it state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources