Ensembl

Variation

variation

Read-onlyIdempotent

"What is [rsID]" / "look up SNP [rs...]" / "variant info for [rsN]" — fetch a genetic variation record by ID (e.g. rs56116432). Returns alleles, genomic location, clinical significance, gene mappings. Use for SNP lookups, pharmacogenomics, GWAS follow-up.

Input Schema

TableJSON Schema

Name	Required	Description
`species`	Yes
`assembly`	No	Human genome build: "GRCh38" (the default) or "GRCh37" (= hg19). Coordinates you pass and coordinates you get back are both in this build. Older variant lists, spreadsheets and published tables are usually GRCh37.
`variant_id`	Yes	e.g. "rs56116432"

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Ensembl variation ID
`end`	No	End coordinate
`name`	No	Variant name/ID
`class`	No	Variant class (SNP, indel, etc)
`start`	No	Start coordinate
`strand`	No	Strand
`alleles`	No	Alleles
`seq_region_name`	No	Chromosome
`ancestral_allele`	No	Ancestral allele

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / assembly

Added value: +{
+  "description": "Human genome build: \"GRCh38\" (the default) or \"GRCh37\" (= hg19). Coordinates you pass and coordinates you get back are both in this build. Older variant lists, spreadsheets and published tables are usually GRCh37.",
+  "type": "string"
+}

Changed2 schema fields changedMay 27, 2026

addedInput schema / examples

Added value: +[
+  {
+    "species": "human",
+    "variant_id": "rs56116432"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Variation record by variant ID",
+  "properties": {
+    "alleles": {
+      "description": "Alleles",
+      "items": {
+        "properties": {
+          "allele": {
+            "description": "Allele sequence",
+            "type": "string"
+          },
+          "frequency": {
+            "description": "Allele frequency",
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "ancestral_allele": {
+      "description": "Ancestral allele",
+      "type": "string"
+    },
+    "class": {
+      "description": "Variant class (SNP, indel, etc)",
+      "type": "string"
+    },
+    "end": {
+      "description": "End coordinate",
+      "type": "integer"
+    },
+    "id": {
+      "description": "Ensembl variation ID",
+      "type": "string"
+    },
+    "name": {
+      "description": "Variant name/ID",
+      "type": "string"
+    },
+    "seq_region_name": {
+      "description": "Chromosome",
+      "type": "string"
+    },
+    "start": {
+      "description": "Start coordinate",
+      "type": "integer"
+    },
+    "strand": {
+      "description": "Strand",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

First observedMay 16, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already indicate readOnly, idempotent, openWorld, and destructive false, so the safety profile is covered. The description adds that the tool 'fetches' and 'returns' data, but it does not add extra behavioral context such as rate limits, authentication, or any edge-case side effects; this is adequate but not rich.

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 compact, front-loaded with example queries, and contains no redundant or vague filler. Every sentence adds useful information: what it fetches, what it returns, and when to use it.

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 read-only lookup tool, the description gives enough context: input examples, output content, and use cases. The assembly parameter is well explained in the schema, and the output schema exists, so the description does not need to enumerate every field.

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?

Two of three parameters have useful schema descriptions: assembly explains GRCh38 vs GRCh37, and variant_id gives an example. The required species parameter has no description in the schema and none in the tool description, so an agent must infer its acceptable values. Schema coverage is moderate, so the description does not need to fully compensate, but the species gap remains.

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 fetches a genetic variation record by ID and gives concrete example queries. It also lists the returned data (alleles, genomic location, clinical significance, gene mappings) and typical use cases, so an agent can immediately tell what the tool does.

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 explicit use cases ('Use for SNP lookups, pharmacogenomics, GWAS follow-up') and example user phrasings. It does not explicitly contrast this tool with sibling tools such as vep or sequence, but the purpose is specific enough that an agent can usually select it correctly.

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

All Ensembl tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.