ensembl-mcp-server
Server Details
Look up genes, fetch sequences, predict variant consequences, find orthologs and xrefs via Ensembl.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool targets a distinct genomic function: species listing, gene lookup, sequence fetch, homology search, cross-reference retrieval, variant prediction, and region query. There is no overlap in purpose, and descriptions are detailed enough to prevent confusion between tools.
All tool names follow a consistent `ensembl_<verb>_<object>` pattern (e.g., `ensembl_get_homology`, `ensembl_lookup_gene`). Verbs and nouns are clear, descriptive, and uniformly structured, making the API predictable.
7 tools is well-scoped for an Ensembl MCP server. It provides essential operations for genomic data discovery and analysis without being overly sparse or overwhelmingly numerous. Each tool serves a clear purpose in typical research workflows.
The set covers the full lifecycle of genomic querying: from species discovery (`list_species`) to gene lookup (`lookup_gene`), sequence retrieval (`get_sequence`), homology analysis (`get_homology`), cross-reference integration (`get_xrefs`), variant impact prediction (`predict_variant`), and region-based feature query (`query_region`). No obvious gaps for the intended domain.
Available Tools
7 toolsensembl_get_homologyGet Gene HomologsARead-onlyIdempotentInspect
Find orthologs and/or paralogs of a gene across species. Returns each homolog's stable ID, species, homology type (ortholog_one2one, ortholog_one2many, paralog_many2many, etc.), perc_id (percent identity), perc_pos (percent positives), and taxonomy level. Essential for cross-species research — for example, "what is the mouse equivalent of human TP53?" or "how conserved is BRCA2 across mammals?". Provide either symbol + species or a stable gene ID. Target species can be filtered to a single species or left open to return all available homologs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Ensembl stable gene ID (e.g. ENSG00000139618). Use ensembl_lookup_gene to get the stable ID from a symbol. Cannot be combined with symbol. | |
| type | No | Type of homologs to return. orthologues: genes related by speciation (cross-species equivalents). paralogues: genes related by duplication (within or across species). all: both orthologs and paralogs. | orthologues |
| symbol | No | Gene symbol in the source species (e.g. BRCA2, TP53). Species defaults to homo_sapiens; set species for other organisms. Cannot be combined with id. | |
| species | No | Source species (the species the query gene belongs to) in Ensembl internal format. Default is homo_sapiens. Use ensembl_list_species to discover valid values. | homo_sapiens |
| target_species | No | Filter to homologs in a single target species (e.g. mus_musculus for mouse). Omit to return homologs across all available species. Use ensembl_list_species to discover valid values. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no homologs are found. |
| queryId | Yes | The resolved Ensembl gene ID used for the homology query. |
| homologs | Yes | Homologous genes found for the query gene. |
| queryType | Yes | The homology type queried (orthologues, paralogues, or all). |
| totalCount | Yes | Total number of homologs returned. |
| querySpecies | Yes | The source species used for the query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description reinforces this by showing it's a query tool and adds behavioral details such as the types of homology returned (ortholog_one2one, etc.) and that results can be filtered by target species. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~80 words) with a clear front-loaded purpose. Every sentence contributes meaningful information without repetition or fluff. It efficiently covers purpose, return fields, examples, and parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately explains return fields. It covers all 5 parameters and their constraints. Minor gaps include no mention of error handling or edge cases (e.g., no homologs found), but overall it is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the relationship between id and symbol (cannot combine), default species, and how target_species filtering works. It also provides examples that clarify parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds orthologs/paralogs of a gene across species. It names specific resources (homologs), uses a strong verb ('find'), and distinguishes from sibling tools like ensembl_get_sequence and ensembl_lookup_gene by focusing on cross-species homology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with examples (e.g., mouse equivalent of human TP53) and explains input options (symbol+species vs stable ID). However, it lacks explicit when-not-to-use guidance or comparisons to alternatives for other tasks (e.g., retrieving sequences).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ensembl_get_sequenceGet SequenceARead-onlyIdempotentInspect
Fetch the DNA, cDNA, CDS, or protein sequence for a gene, transcript, protein, or genomic region. Returns the sequence with its stable ID, molecule type, and character count — large sequences are returned in full but the length is stated so callers can budget context. The type parameter selects which sequence is fetched: genomic (default, includes introns), cdna (spliced transcript), cds (coding sequence only), protein. For region mode, set id to the format species:chr:start-end (e.g. homo_sapiens:13:32315086-32400268) and set species. Protein sequences require a transcript or protein stable ID (ENST…/ENSP…), not a gene ID — use ensembl_lookup_gene with expand_transcripts=true to get the canonical transcript ID first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ensembl stable ID (ENSG…, ENST…, ENSP…) or region in the format species:chr:start-end (e.g. homo_sapiens:13:32315086-32400268) for region mode. For genomic region queries, species is also required. | |
| type | No | Sequence type to retrieve. genomic: full genomic DNA including introns (default). cdna: spliced transcript sequence (requires ENST… ID). cds: coding sequence only, no UTRs (requires ENST… ID with coding transcript). protein: amino acid sequence (requires ENST… or ENSP… ID). | genomic |
| species | No | Species in Ensembl internal format (e.g. homo_sapiens). Required for region mode (when id is a species:chr:start-end string). Optional for stable ID lookups — Ensembl infers species from the ID prefix. | |
| expand_3prime | No | Number of base pairs to extend downstream (3' direction) of the requested feature. Default 0. Only applies to genomic sequences and region queries. | |
| expand_5prime | No | Number of base pairs to extend upstream (5' direction) of the requested feature. Default 0. Only applies to genomic sequences and region queries. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | The stable ID or region used for the lookup. |
| seq | Yes | The full sequence. DNA sequences use IUPAC nucleotide codes (ACGT + ambiguity codes). Protein sequences use single-letter amino acid codes. Large genomic sequences (e.g. 85 kb for BRCA2) are returned in full. |
| type | Yes | Sequence type returned (genomic, cdna, cds, or protein). |
| length | Yes | Sequence length in characters — nucleotides for genomic/cdna/cds, amino-acid residues for protein. Use this to budget context window usage before processing the sequence. |
| description | No | Sequence description from Ensembl, if provided. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds notable context beyond these: it states that large sequences are returned in full but the length is provided for context budgeting. This helps manage expectations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states the main purpose, followed by details on types and edge cases. It is moderately long but every sentence adds value. Could be slightly more concise by removing redundant phrasing, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, multiple sequence types, region mode), the description covers all key aspects: parameter interactions, required vs optional fields, error-prone scenarios (protein vs gene ID), and even suggests a sibling tool for a prerequisite step. An output schema exists, so return format is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds significant value beyond the schema: it explains the relationship between 'type' and 'id' (e.g., protein requires transcript/protein ID) and provides region format examples. This compensates for the schema's default descriptions and elevates the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches sequences (DNA, cDNA, CDS, or protein) for various biological entities, distinguishing it from sibling tools like ensembl_get_homology or ensembl_get_xrefs. The verb 'Fetch' and specific resource types make the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each 'type' parameter and provides crucial context for protein sequences (requires transcript/protein ID, not gene ID). It also directs users to ensembl_lookup_gene for obtaining transcript IDs. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ensembl_get_xrefsGet Cross-Database ReferencesARead-onlyIdempotentInspect
Retrieve cross-database references for a gene or feature — HGNC, UniProt, EntrezGene, OMIM, RefSeq, Reactome, and others. Returns each xref with its database name, primary ID, display ID, and description. The dbname filter narrows to specific databases; omit to return all xrefs. IDs returned here chain to protein (pubchem via UniProt), literature (pubmed via PubMed IDs), disease (OMIM via MIM_GENE), and pathway (Reactome) resources. Requires an Ensembl stable ID — use ensembl_lookup_gene to get the ENSG… ID first. Common dbname values: HGNC, Uniprot_gn, EntrezGene, MIM_GENE, RefSeq_mRNA, RefSeq_peptide, Reactome, GO (Gene Ontology), ChEMBL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ensembl stable gene ID (ENSG…) or transcript ID (ENST…). Use ensembl_lookup_gene to get the stable ID from a gene symbol. xrefs/id returns the full cross-reference set (56+ entries for well-annotated genes like BRCA2). | |
| dbname | No | Filter to a specific external database by its Ensembl internal name. Examples: HGNC (HGNC gene ID), Uniprot_gn (UniProt gene name), EntrezGene (NCBI Gene ID), MIM_GENE (OMIM disease gene), RefSeq_mRNA (NCBI RefSeq transcript), Reactome (pathway IDs), GO (Gene Ontology terms). Omit to return all available xrefs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| xrefs | Yes | Cross-database references for the queried Ensembl ID. |
| notice | No | Guidance when no cross-references are found. |
| queriedId | Yes | The Ensembl stable ID that was queried. |
| totalCount | Yes | Total number of cross-references returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by explaining the return structure (fields: database name, primary ID, display ID, description) and how the returned IDs can chain to other resources (proteins, literature, diseases, pathways). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that effectively front-loads the main purpose, then provides usage order, then detail. It is concise with no wasted words, though it could be slightly more structured (e.g., bullet points) for even easier parsing. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (not shown but stated), the description explains what is returned and the relationship to other resources. It also covers the prerequisite tool (ensembl_lookup_gene) and the optional filtering. This is fairly complete for a lookup tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond what the schema provides: it specifies that 'id' must be an Ensembl stable ID and gives examples of common dbname values (e.g., HGNC, Uniprot_gn, EntrezGene). This helps the agent select appropriate parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves cross-database references for a gene or feature, listing specific databases (HGNC, UniProt, etc.). It differentiates from siblings by explicitly mentioning the prerequisite use of ensembl_lookup_gene to obtain the stable ID, and its function is distinct from other tools like ensembl_get_homology or ensembl_get_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: it requires an Ensembl stable ID and directs users to ensembl_lookup_gene first. It also explains how to use the dbname filter to narrow results. However, it does not explicitly state when not to use this tool, though the context is clear from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ensembl_list_speciesList Ensembl SpeciesARead-onlyIdempotentInspect
List species supported by Ensembl with display name, common name, assembly, taxon ID, and division. Required discovery step — species names like homo_sapiens are opaque to non-biologists and are the input format every other Ensembl tool expects. Filter by division to limit results; use nameContains to find a species by partial name match. Returns the full species catalog when no filters are applied (EnsemblVertebrates has ~250 species; all divisions combined have ~1,000+).
| Name | Required | Description | Default |
|---|---|---|---|
| division | No | Filter to a specific Ensembl division. EnsemblVertebrates includes human, mouse, zebrafish, and other vertebrates. EnsemblPlants covers crop and model plant genomes. EnsemblFungi, EnsemblMetazoa, EnsemblProtists cover non-vertebrate model organisms. Omit to return all divisions. | |
| nameContains | No | Case-insensitive substring filter applied locally after fetching. Matches against species name, display name, and common name. Example: "sapiens" matches homo_sapiens; "mouse" matches mus_musculus. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when the filter matches no species. |
| species | Yes | Species matching the filter criteria, sorted by internal name. |
| totalCount | Yes | Total number of matching species after local filtering. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations (readOnlyHint, idempotentHint). Explains that nameContains is a case-insensitive substring filter applied locally after fetching, which is critical for understanding performance. Also notes the size of the result set (250 for vertebrates, 1000+ for all divisions), helping agents manage expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose. First sentence defines the action and output. Second explains importance. Third gives filter guidance. Fourth sets expectations on result size. No redundant or vague language. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage context, filter guidance, and result size. The presence of an output schema means return value details are already covered. The description is complete for an agent to decide when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema's descriptions. For division, it provides examples of which species each division includes. For nameContains, it clarifies case-insensitivity and that it matches against species name, display name, and common name. This enhances the agent's understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists species with specific attributes (display name, common name, assembly, taxon ID, division). Distinguishes itself as a required discovery step for other Ensembl tools, which expect species names like homo_sapiens. This differentiates it from sibling tools that operate on specific species.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly identifies this as a discovery step before using other tools. Describes how to filter by division and nameContains, including example values. Implicitly advises against use when you already know the species identifier. Does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ensembl_lookup_geneLookup GeneARead-onlyIdempotentInspect
Resolve a gene by symbol + species (or by stable ID) to its Ensembl ID, genomic location (chr:start-end:strand), biotype, description, and transcript list. Entry point for most workflows — the stable ID and coordinates returned here are inputs to other tools. Accepts both symbol lookup (BRCA2 + homo_sapiens) and direct ID lookup (ENSG00000139618). Supports batch lookup of up to 20 IDs or symbols in one call via the ids or symbols field. Provide exactly one of symbol, id, ids, or symbols. For symbol lookups species defaults to homo_sapiens (override for other organisms); for ID lookups species is not needed. Use ensembl_list_species to discover valid species names.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Ensembl stable gene ID (e.g. ENSG00000139618 or ENSG00000139618.7 with version). Species is not required for ID lookup. | |
| ids | No | Batch lookup: up to 20 Ensembl stable IDs (ENSG…, ENST…). Returns a succeeded/failed split. Provide exactly one of symbol, id, ids, or symbols. | |
| symbol | No | Gene symbol to look up (e.g. BRCA2, TP53, EGFR). Species defaults to homo_sapiens; set species for other organisms. Case-insensitive in most species. | |
| species | No | Species in Ensembl internal format: lowercase scientific name with underscores (e.g. homo_sapiens, mus_musculus, danio_rerio). Optional for symbol lookups — defaults to homo_sapiens; set it for other organisms. Use ensembl_list_species to discover valid values. | |
| symbols | No | Batch lookup: up to 20 gene symbols. Species defaults to homo_sapiens; set species for other organisms. Returns a succeeded/failed split. Provide exactly one of symbol, id, ids, or symbols. | |
| expand_transcripts | No | When true, include the full transcript list in the response. Each transcript has its ID, biotype, canonical flag, and coordinates. Default is false to keep responses compact. |
Output Schema
| Name | Required | Description |
|---|---|---|
| gene | No | Single gene record. Present for symbol or id lookups. |
| batch | No | Batch results. Present for ids or symbols lookups. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds batch limits (20), succeeded/failed split, expand_transcripts behavior, and default species. Adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with main action. Slightly verbose with repeated 'Provide exactly one' but overall efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers all key aspects: input modes, batch behavior, default species, parameter interrelations, and link to list_species. Output schema exists, so no need to detail return structure. Complete for a lookup tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description reinforces mutual exclusivity, gives example IDs/symbols, explains default species, and notes case-insensitivity for symbols – adding flavor beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a gene to Ensembl ID, genomic location, biotype, description, and transcript list. It distinguishes from siblings by calling it the entry point for most workflows and notes that returned IDs/coordinates feed other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use symbol+species vs ID lookup, batch via ids/symbols, mutual exclusivity of inputs, default species, and pointer to ensembl_list_species for valid species names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ensembl_predict_variantPredict Variant EffectARead-onlyIdempotentInspect
Predict the functional consequences of a sequence variant using the Ensembl Variant Effect Predictor (VEP). Accepts HGVS notation (transcript-relative, e.g. ENST00000380152.8:c.2T>A, or genomic, e.g. 13:g.32316462T>A) and also region+allele format (chr:start:end:strand/allele, e.g. 1:65568:65568:1/T). Returns the most severe consequence term, affected transcripts and genes, impact level (HIGH/MODERATE/LOW/MODIFIER), and any colocated known variants with clinical significance. HGVS input: provide the full notation including transcript version for best results. Region+allele input: use Ensembl chromosome naming (no chr prefix for vertebrates).
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | Species in Ensembl internal format. Default is homo_sapiens. For non-human variants, set the appropriate species (e.g. mus_musculus for mouse). Use ensembl_list_species to discover valid values. | homo_sapiens |
| variant | Yes | Variant in one of two formats: (1) HGVS notation — transcript-relative: ENST00000380152.8:c.2T>A; genomic: 13:g.32316462T>A; (2) Region+allele: chr:start:end:strand/allele — e.g. 1:65568:65568:1/T. For region+allele, strand is 1 (forward) or -1 (reverse); chromosome names use no "chr" prefix for vertebrates. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no results are returned. |
| results | Yes | VEP consequence records — typically one per input variant. Multiple records appear when a single notation matches multiple genomic positions. |
| totalCount | Yes | Number of VEP consequence records returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, idempotent behavior. The description adds details: returns most severe consequence, affected transcripts, impact levels, and colocated known variants. It also provides best practice tips (include transcript version). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that efficiently conveys purpose, input formats, outputs, and usage tips. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, a stated output schema, and annotations covering safety/idempotency, the description is fully complete. It covers input formats, output contents, species discovery, and best practices, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds significant meaning beyond schema: for 'variant', it explains the two allowed formats with examples; for 'species', it notes default and discovery via ensembl_list_species. This clarifies usage beyond the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts functional consequences of sequence variants using Ensembl VEP, and specifies input formats (HGVS and region+allele) and output (consequence, transcripts, impact level, known variants). It is distinct from sibling tools which cover homology, sequences, xrefs, species, gene lookup, and regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use (for variant effect prediction) and how to format inputs (HGVS with transcript version recommended, region+allele with Ensembl chromosome naming). It references ensembl_list_species for valid species values. However, it does not explicitly exclude alternative tools or 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.
ensembl_query_regionQuery Genomic RegionARead-onlyIdempotentInspect
Find genomic features overlapping a chromosomal region: genes, transcripts, variants, regulatory elements, or exons. Returns each feature with its stable ID, type, location, biotype, and name. Useful for "what's in this locus?" and for seeding follow-up lookups. Region format is chr:start-end (e.g. 13:32315086-32400268 for the BRCA2 locus). Chromosome names use Ensembl format — no "chr" prefix for vertebrates (use 13 not chr13). The feature parameter defaults to gene only to prevent overwhelming returns — requesting variation in an 85 kb region returns 44,000+ entries. Explicitly include variation, regulatory, transcript, or exon only when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Genomic region in chr:start-end format (e.g. 13:32315086-32400268). Chromosome names use Ensembl format — no "chr" prefix for vertebrates (13, not chr13). For large regions (>100 kb), limit to gene feature type to avoid overwhelming results. | |
| biotype | No | Optional biotype filter (e.g. protein_coding, lncRNA, SNV). Applied server-side by Ensembl. Not all feature types support biotype filtering. | |
| feature | No | Feature types to retrieve. Default is gene only. Requesting variation in a large region can return tens of thousands of features. Include variation only for targeted small regions (single gene loci or smaller). | |
| species | Yes | Species in Ensembl internal format (e.g. homo_sapiens, mus_musculus). Use ensembl_list_species to discover valid values. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Warning or guidance about the result set. |
| region | Yes | The region queried, as provided. |
| species | Yes | The species queried. |
| features | Yes | Genomic features found in the requested region. |
| totalCount | Yes | Number of features returned. Note: very large regions may return truncated results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral nuances: default feature='gene' to prevent overwhelming returns, large region warnings, and chromosome format requirements. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear flow: purpose, return contents, usage example, warnings. Every sentence adds value, no redundancy. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 2 required, and an output schema, the description covers all necessary context: region format, feature defaults, size warnings, and follow-up use. Output schema reduces need to describe returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by reinforcing region format example, explaining the default and warning for 'feature', and giving practical usage context. Some parameters (e.g., biotype) are not further elaborated, but overall it supplements schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it finds genomic features overlapping a chromosomal region, listing specific feature types (genes, transcripts, variants, etc.). It distinguishes from sibling tools by focusing on region queries, unlike homology, sequence, or lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: useful for 'what's in this locus?', warns against using variation in large regions, specifies chromosome naming format, and suggests when to exclude certain features. Lacks explicit comparison to sibling tools but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!