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.6/5 across 7 of 7 tools scored.
Each tool targets a distinct Ensembl endpoint: homology, sequence, cross-references, species list, gene lookup, variant prediction, and region query. The descriptions clearly differentiate their purposes, leaving no ambiguity for an agent.
All tools follow a consistent 'ensembl_verb_noun' pattern: ensembl_get_homology, ensembl_get_sequence, etc. This uniformity makes the tool set predictable and easy to navigate.
With 7 tools, the server is well-scoped for a read-only Ensembl interface. It provides essential query functions without overwhelming the user, covering species lookup, gene resolution, sequence retrieval, and variant prediction.
The tool set covers the full lifecycle of typical Ensembl queries: discover species, look up genes, fetch sequences, find homologs, retrieve cross-references, query regions, and predict variant effects. There are 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 used together 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). Requires species to be set. Cannot be used together 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 declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds valuable behavioral context by listing return fields (stable ID, species, homology type, percentages) and stating it is 'Essential for cross-species research.' 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 concise (~100 words across three sentences). The first sentence immediately states the action and return fields; the second provides a motivating example; the third gives usage constraints. Every sentence is informative with no redundancy.
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 5 parameters, high schema coverage, and existence of an output schema, the description covers all necessary context: how to specify the gene, filtering options, and expected return fields. It does not need to detail return structure as that is in the output schema. For a read-only query tool, it is fully complete.
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 covers 100% of parameters with descriptions. The tool description adds usage-level context: explains the mutually exclusive id and symbol parameters, default species, and how target_species filtering works. It also references other tools for value discovery. This adds moderate value beyond the schema but does not introduce new semantic details not already implied.
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 function: 'Find orthologs and/or paralogs of a gene across species.' It uses specific verbs and resources, and distinguishes itself from sibling tools (e.g., ensembl_get_sequence, ensembl_lookup_gene) by focusing on homology across species. Examples like 'what is the mouse equivalent of human TP53?' reinforce the specific purpose.
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: provide symbol+species or stable gene ID, and optionally filter by target species. It gives concrete examples of research scenarios. However, it does not explicitly state when NOT to use this tool versus alternatives, though it references ensembl_lookup_gene for ID retrieval, which indirectly helps.
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). |
| lengthInBp | Yes | Sequence length in characters (nucleotides or amino acids). 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 already indicate read-only and idempotent behavior. The description adds valuable behavioral details: large sequences are returned in full with length stated, and it explains the effect of the type parameter. 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, starting with the core purpose then providing details. It is concise but comprehensive; a minor reduction in length could improve conciseness slightly, but every sentence adds value.
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, enum, region format) and the existence of an output schema, the description covers all necessary aspects for correct usage, including mode selection, prerequisites, and parameter behavior.
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?
The input schema already has 100% coverage with descriptions for all 5 parameters. The description adds extra context, such as the format for region mode and the requirement that protein sequences need a transcript or protein ID, which enhances understanding 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 starts with a clear verb ('Fetch') and resource ('sequence'), and specifies the types of sequences and identifiers it accepts. It distinguishes itself from sibling tools like ensembl_lookup_gene by focusing on sequence retrieval.
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 is given on when to use each sequence type, prerequisites for protein sequences, and instructions for region mode. It also references a sibling tool (ensembl_lookup_gene) for obtaining transcript IDs when needed.
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. For symbol lookup, species is required; for ID lookup, 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. Cannot be combined with symbol or id. | |
| symbol | No | Gene symbol to look up (e.g. BRCA2, TP53, EGFR). Requires species to be set. 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). Required when using symbol. Default is homo_sapiens for symbol-based lookups. Use ensembl_list_species to discover valid values. | |
| symbols | No | Batch lookup: up to 20 gene symbols. Requires species to be set. Returns a succeeded/failed split. Cannot be combined with symbol, id, or ids. | |
| 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 already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds value by disclosing batch limits (20), the succeeded/failed split response, and the expand_transcripts default behavior. No contradiction 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 with a summary first, then details. It is informative without being overly verbose. Minor redundancy (e.g., mentioning batch limits twice) could be trimmed, 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 output schema exists, the description adequately covers return values. It mentions the transcript list controlled by expand_transcripts, the succeeded/failed split for batch calls, and the entry-point role. No gaps remain.
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%, so baseline is 3. The description adds meaning beyond the schema: clarifies that species is required only for symbol/symbols, not for id/ids, explains the batch behavior, and notes case-insensitivity of symbols. This exceeds 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 uses a specific verb ('Resolve') and clearly states the resource (gene) and results (Ensembl ID, location, biotype, etc.). It distinguishes from siblings by positioning itself as the entry point for most workflows, and the input schema details confirm two distinct lookup modes.
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 explicitly states when to use (symbol lookup with species, or by ID, or batch), when not to combine parameters, and references ensembl_list_species for discovering species names. This provides clear guidance on alternatives and exclusions.
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!