Skip to main content
Glama

gnomad-genetics-mcp-server

gnomad-genetics-mcp-server: get variant cooccurrence

gnomad_get_variant_cooccurrence
Read-onlyIdempotent

Estimate whether two variants in the same gene sit on different haplotypes (in trans — compound heterozygous) or on the same one (in cis), from gnomAD v2.1 exome genotypes: the probability of compound heterozygosity and the genotype and haplotype counts behind it, overall and per genetic-ancestry group. For a proband with two rare heterozygous variants in a recessive gene and no parental samples. Takes exactly two GRCh37 chrom-pos-ref-alt IDs and always reads gnomad_r2_1, the only dataset gnomAD serves co-occurrence for, echoing it with GRCh37. A GRCh38 ID can name a different GRCh37 variant or none, so convert GRCh38 IDs first: gnomad_get_variant on dataset gnomad_r2_1 lists their GRCh37 IDs as candidates only when the ID fails there as variant_not_found_other_build; an ID gnomad_r2_1 finds returns a different variant. gnomAD answers only for two different coding or UTR variants of one gene, both in its exome samples with exome allele frequency of 5% or less; any other pair fails as cooccurrence_unavailable with gnomAD's reason. Each count key names variant_ids[0]'s genotype or allele first and variant_ids[1]'s second, and variant_ids can list the pair in another order than sent. The notice carries gnomAD's calibration caveat and its browser's reading of the probability. gnomAD's browser also notes when the pair is found in phase as a multi-nucleotide variant; this tool does not check for one. Data source: gnomAD (Broad Institute) — https://gnomad.broadinstitute.org/

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "variants": "<variants>"
    },
    "name": "gnomad_get_variant_cooccurrence"
  }
}

Input Schema

NameRequiredDescriptionDefault
variantsYesThe two variants to phase, as GRCh37 chrom-pos-ref-alt IDs. Order does not matter: variant_ids in the output gives the order the counts use.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNognomAD's calibration caveat and its browser's reading of the probability for this pair. When no sample carries both variants, it adds that the counts come from each variant's separate data and do not account for samples not covered at both sites; that coverage sentence appears only then.
datasetNoDataset the counts come from — always gnomad_r2_1, the only one gnomAD serves co-occurrence for.
populationsNoThe same counts per genetic-ancestry group, in gnomAD's order.
variant_idsNoThe pair in gnomAD's order, which labels every count: variant_ids[0] is the first token of each key, variant_ids[1] the second. Can differ from the order sent.
genotype_countsNoSamples per genotype pair. Each key names variant_ids[0]'s genotype first and variant_ids[1]'s second: ref (homozygous reference), het (heterozygous), hom (homozygous alternate).
haplotype_countsNognomAD's estimated haplotype counts, fractional where samples heterozygous for both variants leave the phase to its EM estimate. Each key names variant_ids[0]'s allele first and variant_ids[1]'s second.
reference_genomeNoReference build of variant_ids — always GRCh37.
p_compound_heterozygousNoEstimated probability that the two variants lie on different haplotypes (in trans, compound heterozygous). Null when gnomAD computes none, as when either variant has no carrier among these samples — never read null as 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description pins the dataset (always gnomad_r2_1, the only dataset gnomAD serves co-occurrence for), enumerates the eligibility rules that can cause failure, names the error code cooccurrence_unavailable, warns that an ID gnomad_r2_1 does find denotes a different variant, and discloses the calibration caveat carried in the notice. It even flags a known non-behavior: phase-resolved multi-nucleotide variants are not checked.

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?

Purpose and eligibility come first, then dataset pinning, then the build-conversion hazard, then failure modes and output-key ordering — a sound front-loaded sequence with no filler sentences. It is dense, though, and the sentence contrasting the two gnomad_get_variant outcomes is a single convoluted clause chain that slows reading.

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?

For a two-variant phasing tool with an output schema already present, the description supplies everything an agent needs to call it correctly or to recognize a legitimate failure: required build, dataset pinning, eligibility thresholds, error code, and how to read the count keys. The caveats about gnomAD's calibration notice and unchecked MNVs round it out.

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 schema already documents the single parameter at full coverage, including chrom-pos-ref-alt format and order-invariance, so the baseline is 3. The description adds genuine meaning by explaining why GRCh37 is mandatory — a GRCh38 ID can silently denote a different GRCh37 variant — which the schema does not convey. It also clarifies that variant_ids in the output may be reordered relative to the input.

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 opening sentence names a specific verb and analytical result — estimating whether two variants are in trans or cis, with the probability of compound heterozygosity and the counts behind it — and scopes it to gnomAD v2.1 exomes and per-ancestry groups. It is plainly distinct from the generic lookup sibling gnomad_get_variant.

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?

"For a proband with two rare heterozygous variants in a recessive gene and no parental samples" gives an explicit clinical scenario, and the description states when the tool is unavailable (non-coding/non-UTR, absent from exomes, exome AF above 5%). It also names the alternative path — using gnomad_get_variant on gnomad_r2_1 to lift a GRCh38 ID to GRCh37 — and the exact failure signal (variant_not_found_other_build) that justifies that detour.

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.