Skip to main content
Glama

togovar_search_variant

Read-only

Find human genomic variants by gene, disease, chromosome, or frequency, with population allele frequencies, clinical significance, and pathogenicity predictions.

Instructions

Search TogoVar for human genome variants with population frequencies.

TogoVar integrates allele frequencies from gnomAD, ToMMo (Japanese), NCBN, GEM-J, JGA, and BioBank Japan, plus ClinVar + MGeND clinical significance and SIFT/PolyPhen/AlphaMissense predictions — data with no SPARQL counterpart elsewhere in TogoMCP.

All filters are optional and combined with AND. Supply zero filters to browse; but scope tightly — the database holds ~1 billion variants.

COUNTS: total is the size of the whole REST backend (1,097,708,150) and is constant across queries; filtered is the count matching your filters. Note the REST backend is LARGER than TogoMCP's togovar SPARQL graph (~2.8x: the SPARQL side is the annotated subset, 390,725,782), so REST counts will not match SPARQL COUNT(*) — they measure different sets.

PAGING CAP: the API allows offset + limit <= 10,000 and returns HTTP 400 beyond it, so a result set larger than 10,000 cannot be fully paged. Narrow the filters until filtered <= 10,000 to enumerate one exhaustively.

STATISTICS SCOPE (stat=True): all facets are scoped to the filtered set, but they count at different granularities. type counts per variant (sums to filtered); dataset per variant-cohort; consequence per variant-TRANSCRIPT (VEP fan-out, so its sum is filtered x transcripts per variant — ~5-6 for a typical gene, 400+ in transcript-dense loci like BRCA1); significance per variant-condition record. So consequence/ significance sums exceed filtered and must NOT be summed against it (they are not per-variant counts). See statistics_caveats for the per-facet rule.

ROUND-TRIP TO SPARQL: gate on tgv_id. It is NULL for variants that exist in the REST backend but NOT in the (smaller) SPARQL subset — including some ClinVar-Pathogenic ones. variant_iri is emitted ONLY when tgv_id is non-null, so a non-null variant_iri is safe to query in the togovar SPARQL graph; a row with tgv_id: null has no SPARQL record at all, and REST is the only source for it.

TWO-STEP WORKFLOW for gene/disease filters: 1. search_gene("ALDH2") -> hgnc_id -> pass as gene_hgnc_id. 2. search_disease("breast cancer") -> mondo_id -> pass as disease_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statNoIf True, also return match counts (`total`, `filtered`) and the aggregate breakdown (counts by dataset, type, consequence, significance). REQUIRED to get a count — e.g. "how many variants match". Left False by default because computing the aggregation is the slow part of the query; use stat=False when you only need rows. See STATISTICS SCOPE above — every facet is scoped to the filtered set, but they count at different granularities, so only `type` sums to `filtered`.
stopNo
limitNoMax variant rows to return, in [0, 1000]. Default 100.
startNo
offsetNoRows to skip (pagination). Default 0.
tgv_idNoTogoVar variant ID(s), e.g. "tgv16331".
datasetNoFrequency panel for a frequency filter, e.g. "gnomad_genomes", "gnomad_exomes", "tommo", "ncbn", "gem_j_wga", "jga_wgs", "jga_wes", "jga_snp", "bbj_riken". Sub-populations allowed (e.g. "gnomad_genomes.eas", "ncbn.jpn").
positionNoSingle 1-based site (mutually exclusive with start/stop).
chromosomeNo"1"-"22", "X", "Y", "MT". Required for a positional filter.
disease_idNoMONDO ID(s) (e.g. "MONDO_0007254") or MedGen CUI(s) from `search_disease`.
consequenceNoSO consequence term or label, e.g. "missense_variant", "stop_gained", "frameshift_variant".
gene_hgnc_idNoHGNC ID (integer) from `search_gene` (NOT a symbol).
variant_typeNo"snv", "ins", "del", "indel", "sub".
max_frequencyNo
min_frequencyNo
disease_sourceNoRestrict disease link source(s): "clinvar", "mgend".
include_transcriptsNoIf True, add a `transcripts` list to each row with the per-transcript VEP annotation the REST backend already carries: transcript/gene IDs, SO consequence(+labels), HGVS c/p/g, and per-transcript SIFT/PolyPhen/AlphaMissense. Default False — a variant in a transcript-dense locus (e.g. BRCA1) can carry 400+ transcript annotations, which would dominate the response. Note this means HGVS and per-transcript predictions do NOT require a SPARQL round-trip.
significance_sourceNoRestrict significance source(s): "clinvar", "mgend".
include_full_allelesNoIf True, return full REF/ALT sequences even for large structural variants. Default False summarizes alleles over ~50 bp as "<head>…(<n> bp)" to keep the response inline-readable; `ref_length`/`alt_length` always give the true lengths.
clinical_significanceNoe.g. "pathogenic", "likely_pathogenic", "benign", "uncertain_significance", "risk_factor".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Despite having readOnlyHint and openWorldHint annotations, the description goes far beyond them, disclosing the paging cap of 10,000 with HTTP 400, the peculiarity of `total` being constant, the statistics granularity caveats, and the round-trip to SPARQL conditions. This provides critical behavioral context that annotations do not cover.

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 long but every section serves a purpose: the statistics caveats, paging cap, and SPARQL mapping are critical for correct usage. The use of bold headers and bullet-like structure improves readability, though it could be slightly more concise without losing essential warnings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (20 parameters, output schema, advanced features), the description is remarkably complete. It covers filtering logic, count semantics, statistics pitfalls, paging limitations, SPARQL integration, and workflow prerequisites. This is one of the most thorough descriptions for a complex tool, leaving little ambiguity.

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?

With 80% schema description coverage, many parameters are well-described in the schema, and the description adds value by explaining the `stat` parameter in depth, the two-step workflow for gene_hgnc_id and disease_id, and noting the importance of limiting results. However, some parameters like max_frequency and min_frequency lack description beyond the schema, but the description's coverage is strong.

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

Purpose5/5

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

The description clearly states the verb ('Search') and resource ('TogoVar for human genome variants with population frequencies'). It also differentiates from siblings by emphasizing the integration of allele frequencies and clinical significance, and explicitly mentions 'no SPARQL counterpart elsewhere in TogoMCP', distinguishing it from run_sparql and related tools.

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

Usage Guidelines5/5

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

The description provides extensive guidance on when to use this tool, including a two-step workflow for gene/disease filters (referencing togovar_search_gene and togovar_search_disease). It also explains when not to use SPARQL (when variant lacks tgv_id) and notes the REST backend is larger than SPARQL, helping choose between tools.

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

Install Server

Other Tools

Latest Blog Posts

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/dbcls/togomcp'

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