Skip to main content
Glama
biocontext-ai

nucleotide_archive_mcp

by biocontext-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

RNA Dataset Search - MCP Server

BioContextAI - Registry Tests Documentation

A Model Context Protocol (MCP) server for searching and accessing RNA sequencing datasets from the European Nucleotide Archive (ENA). Find publicly available bulk RNA-seq and single-cell RNA-seq datasets to validate research hypotheses or reproduce published analyses.

Optimized for: Human and mouse disease-related RNA-seq studies with support for bulk, single-cell, and spatial transcriptomics.

Features

  • Disease-Focused Search: Find datasets by disease, organism, and tissue type

  • Advanced Technology Filtering:

    • Simple presets: bulk, single-cell, small-rna, ribo-seq, rna-all

    • Granular control: Filter by 50+ library strategies (RNA-Seq, miRNA-Seq, ChIP-Seq, ATAC-seq, etc.)

    • Source filtering: TRANSCRIPTOMIC, GENOMIC, METAGENOMIC, etc.

  • Common Organism Names: Use "human", "mouse", "rat" instead of scientific names

  • Download Support: Generate wget/curl scripts for downloading FASTQ files

  • Study Metadata: Retrieve comprehensive metadata including PubMed IDs

  • Publication Links: Discover datasets associated with PubMed publications

  • Flexible Queries: Build custom queries with multiple field conditions

  • Field Discovery: Explore available search and return fields

  • Environment Configuration: Customize API endpoints, timeouts, and logging via environment variables

Related MCP server: SCMCP

Available Tools

The MCP server provides 10 specialized tools:

Search & Discovery

  1. search_rna_studies - Unified search with preset filters or advanced library strategy/source filtering

  2. list_library_types - List all 50+ available library strategies and sources

  3. get_study_details - Get comprehensive metadata for a specific study (includes PubMed IDs)

  4. find_studies_by_publication - Find studies associated with a PubMed ID

  5. search_studies_by_keywords - Flexible keyword search across study titles

Download & Access

  1. get_download_urls - Get FTP download URLs for all data files in a study

  2. generate_download_script - Generate bash scripts (wget/curl) for downloading data

Advanced

  1. get_available_fields - Discover searchable and returnable fields for different data types

  2. get_result_types - List all available data types in ENA

  3. build_custom_query - Construct advanced queries with multiple field conditions

Example Use Cases

Simple Searches (Preset Filters)

  • Find human cancer bulk RNA-seq datasets: disease="cancer"

  • Search for single-cell RNA-seq in mouse brain: organism="mouse", tissue="brain", technology="single-cell"

  • Find small RNA sequencing studies: technology="small-rna"

  • Ribosome profiling experiments: technology="ribo-seq"

Advanced Searches (Specific Library Types)

  • ChIP-Seq chromatin studies: library_strategies=["ChIP-Seq"]

  • ATAC-seq accessibility data: library_strategies=["ATAC-seq"]

  • Combined small RNA types: library_strategies=["miRNA-Seq", "ncRNA-Seq"]

  • Any single-cell data: library_sources=["TRANSCRIPTOMIC SINGLE CELL"]

  • Metagenomic RNA: library_sources=["METATRANSCRIPTOMIC"]

Workflow Examples

  • Download FASTQ files from a specific study

  • Discover datasets from a specific publication

  • Generate download scripts with MD5 verification

  • List all available sequencing technologies: list_library_types()

Getting started

Please refer to the documentation, in particular, the API documentation.

You can also find the project on BioContextAI, the community-hub for biomedical MCP servers: nucleotide_archive_mcp on BioContextAI.

Installation

You need to have Python 3.11 or newer installed on your system. If you don't have Python installed, we recommend installing uv.

There are several alternative options to install nucleotide_archive_mcp:

1. Use uvx to run it immediately

After publication to PyPI:

uvx nucleotide_archive_mcp

Or from a Git repository:

uvx git+https://github.com/biocontext-ai/nucleotide_archive_mcp.git@main

2. Include it in one of various clients that supports the mcp.json standard

If your MCP server is published to PyPI, use the following configuration:

{
  "mcpServers": {
    "nucleotide_archive_mcp": {
      "command": "uvx",
      "args": ["nucleotide_archive_mcp"]
    }
  }
}

In case the MCP server is not yet published to PyPI, use this configuration:

{
  "mcpServers": {
    "nucleotide_archive_mcp": {
      "command": "uvx",
      "args": ["git+https://github.com/biocontext-ai/nucleotide_archive_mcp.git@main"]
    }
  }
}

For purely local development (e.g., in Cursor or VS Code), use the following configuration:

{
  "mcpServers": {
    "nucleotide_archive_mcp": {
      "command": "uvx",
      "args": [
        "--refresh",
        "--from",
        "path/to/repository",
        "nucleotide_archive_mcp"
      ]
    }
  }
}

If you want to reuse and existing environment for local development, use the following configuration:

{
  "mcpServers": {
    "nucleotide_archive_mcp": {
      "command": "uv",
      "args": ["run", "--directory", "path/to/repository", "nucleotide_archive_mcp"]
    }
  }
}

3. Install it through pip:

pip install --user nucleotide_archive_mcp

4. Install the latest development version:

pip install git+https://github.com/biocontext-ai/nucleotide_archive_mcp.git@main

Configuration

The server can be configured via environment variables. Copy .env.example to .env and customize:

# ENA API Configuration
ENA_PORTAL_API_BASE=https://www.ebi.ac.uk/ena/portal/api  # Override API base URL
ENA_BROWSER_API_BASE=https://www.ebi.ac.uk/ena/browser/api
ENA_TIMEOUT=30.0                # Request timeout in seconds
ENA_SEARCH_LIMIT=20            # Default search result limit
ENA_MAX_RPS=10.0               # Rate limiting (requests per second)

# Logging
LOG_LEVEL=INFO                 # DEBUG, INFO, WARNING, ERROR, CRITICAL

These settings allow you to:

  • Use custom or mirror ENA API endpoints

  • Adjust timeouts for slow connections

  • Control default result limits

  • Configure rate limiting for large batch operations

  • Set logging verbosity for debugging

Data Citation and Attribution

When using data from ENA in publications, please cite the data appropriately:

How to Cite ENA Data

The top-level Project accession should be cited along with a link to the data in the ENA browser:

"The data for this study have been deposited in the European Nucleotide Archive (ENA) at EMBL-EBI under accession number PRJEBxxxx (https://www.ebi.ac.uk/ena/browser/view/PRJEBxxxx)."

Replace PRJEBxxxx with the actual study accession number from your search results.

Accessing Data in ENA Browser

All accessions can be viewed in the ENA browser:

ORCID Data Claiming

ENA studies can be claimed against your ORCID ID through the EBI Search interface. Search for your projects and click "Claim to ORCID" to link them to your ORCID profile.

Data Policy and Usage

ENA/INSDC Data Policy

This tool accesses data from the European Nucleotide Archive (ENA), which is part of the International Nucleotide Sequence Database Collaboration (INSDC) with DDBJ and GenBank.

Key Points:

  • Open Access: All data in ENA/INSDC databases are freely and publicly accessible

  • No Restrictions: Data have no use restrictions or licensing requirements

  • Redistribution: Free redistribution and use of data is permitted

  • Permanence: All submitted records remain permanently accessible

  • Attribution: Proper citation of original submissions is expected (see above)

Data Availability

Data in ENA can be:

  • Public: Freely accessible through this tool and ENA browser

  • Confidential: Pre-publication data not yet publicly available (not searchable through this tool)

Released data should be cited appropriately in publications and claimed via ORCID where applicable.

Data Standards

ENA promotes data harmonization through:

  • Sample Checklists: Minimum information standards for different data types

  • MIxS Standards: Genomic Standards Consortium (GSC) minimum information standards

  • Community Standards: Research community-developed reporting standards

For more information, see the ENA Data Standards documentation.

Disclaimer

This tool provides access to data from the European Nucleotide Archive (ENA) at EMBL-EBI. The tool is:

  • Independent: Not officially affiliated with or endorsed by ENA, EMBL-EBI, or INSDC

  • Quality: Data quality and accuracy are the responsibility of the original submitters

  • Updates: ENA data and APIs may change; this tool is maintained to reflect current ENA services

  • Support: For issues with ENA data or services, contact ENA Support

The European Nucleotide Archive is developed and maintained at EMBL-EBI under the guidance of the INSDC International Advisory Committee.

Contact

If you found a bug with this MCP server, please use the issue tracker.

For questions about ENA data or services, contact ENA Support.

Acknowledgments

This tool accesses data from:

  • European Nucleotide Archive (ENA) at EMBL-EBI

  • International Nucleotide Sequence Database Collaboration (INSDC)

Special thanks to the ENA team for maintaining the public API and comprehensive documentation.

Available Tools

11 tools
build_custom_queryA

Build a custom ENA query from field conditions.

Usage Tips

Advanced tool for constructing complex queries by combining multiple field conditions with logical operators. Use for precise filtering beyond what search_rna_studies() offers. Call get_available_fields() first to discover searchable field names.

Returns

dict Dictionary containing: - query: The constructed ENA query string - field_count: Number of conditions used - operator: Logical operator used - example_usage: How to use this query with other tools - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault
field_conditionsYesList of conditions, each with "field", "operator" (=, >=, <=, !=, contains), and "value"
operatorNoLogical operator to combine conditions (AND or OR)AND

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, but the description details the return dictionary structure and indicates the tool constructs a query (non-destructive). It could be more explicit about side effects but is clear overall.

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?

Two concise sections (Usage Tips and Returns) plus a one-liner, no fluff, front-loaded with key info. Every sentence adds value.

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

Completeness4/5

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

Given the output schema is described and sibling tools are complex, the description covers purpose, prerequisites, return structure, and use case. Minor gap: no mention of error handling details beyond the error 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?

Schema coverage is 100% with examples; the description adds the usage tip about get_available_fields, which indirectly helps with field_conditions, but doesn't elaborate further on parameter meanings beyond the schema.

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 builds a custom ENA query from field conditions, distinguishing it from search_rna_studies by offering precise filtering.

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?

Explicitly provides when to use: 'for precise filtering beyond what search_rna_studies() offers', and suggests calling get_available_fields first, guiding the agent on prerequisites.

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

find_studies_by_publicationA

Find ENA studies by PubMed ID (API limitation - returns error with workaround).

Usage Tips

ENA Portal API doesn't expose pubmed_id as a searchable field. This tool documents the limitation for LLM awareness. Instead: use search_studies_by_keywords() with publication terms, then call get_study_details() to check the publications array for matching PubMed IDs.

Returns

dict Dictionary containing: - error: API limitation message with recommended workflow - pubmed_id: Provided PubMed ID - count: Always 0 - studies: Always empty list

ParametersJSON Schema
NameRequiredDescriptionDefault
pubmed_idYesPubMed ID to search for. Note: This tool has known API limitations and will return an error with alternative instructions

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses the tool's behavior: it returns an error message with recommended workflow, count always 0, studies empty. No hidden surprises.

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?

Well-structured with headers and bullet points, but could be slightly more concise. Every sentence adds value, but the returns section is somewhat redundant with schema.

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 simple tool with one parameter and an output schema, the description fully covers what to expect, including error handling and alternative workflow. No gaps.

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?

Schema coverage is 100% with description and examples for the single parameter. Description adds context about API limitation but does not significantly augment the parameter's meaning beyond the schema.

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 finds ENA studies by PubMed ID, then immediately notes the API limitation and provides an alternative workflow. It distinguishes itself from sibling tools like search_studies_by_keywords.

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?

Explicitly tells when not to use this tool and provides an alternative: use search_studies_by_keywords() with publication terms, then get_study_details(). This is perfect guidance.

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

generate_download_scriptA

Generate executable bash script to download all study data files.

Usage Tips

After identifying interesting studies, generate a download script for the user to execute. Returns script content and optionally saves to file. Script includes MD5 verification commands. Typical workflow: search_rna_studies() → get_study_details() → generate_download_script().

Returns

dict Dictionary containing: - study_accession: Queried study - script_content: Complete bash script ready to execute - file_count: Number of files the script will download - total_size_gb: Total download size in GB - script_path: Save location (if output_path provided) - message: Success message (if saved to file) - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault
study_accessionYesStudy accession from search results. Accepts SRP/ERP/DRP or PRJNA/PRJEB/PRJDB formats
output_pathNoFile path to save script (e.g., './download.sh'). If None, returns script content without saving. Script will be made executable (chmod 755)
script_typeNoDownload tool to use (wget or curl). wget is recommended for resumable downloads with -nc flagwget
file_formatNoFile format to download (fastq, submitted, or sra). FASTQ is most commonfastq

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the tool optionally saves a script to file (making it executable with chmod 755) and includes MD5 verification commands. It also details the return dictionary. Missing are explicit mentions of overwrite behavior, permissions, or error handling, but overall it is sufficiently transparent for a script generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear header, Usage Tips, and Returns section. It is concise but comprehensive, front-loading the purpose. Slightly could be trimmed, but overall efficient.

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

Completeness4/5

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

Given the schema coverage is 100% and an output schema exists (though not shown), the description covers purpose, usage workflow, and return values. It could mention idempotency or specific error conditions, but it is largely complete for a script generation tool.

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?

Schema coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema's descriptions for each parameter; it focuses on usage and returns. No additional parameter semantics are provided.

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 opens with a specific verb+resource: 'Generate executable bash script to download all study data files.' This clearly distinguishes it from siblings like get_download_urls (URLs) and search_rna_studies (search).

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 Usage Tips section explicitly states 'After identifying interesting studies, generate a download script' and provides a typical workflow: search_rna_studies() → get_study_details() → generate_download_script(). This gives clear context for when to use it, though it does not explicitly list when not to use it or alternative tools.

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

get_available_fieldsA

Get available search and return fields for an ENA result type.

Usage Tips

Use to discover what fields you can search on and what metadata fields are available for a given data type in ENA. Helpful for building custom queries with build_custom_query().

Returns

dict Dictionary containing: - result_type: The queried result type - search_fields: List of searchable fields with id, description, type (if requested) - search_fields_count: Number of search fields (if requested) - return_fields: List of returnable fields with id, description, type (if requested) - return_fields_count: Number of return fields (if requested) - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault
result_typeNoType of ENA data to query (read_study, study, sample, read_run, read_experiment, analysis)read_study
field_categoryNoWhich fields to return (all, search, return)all

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. It describes the return structure but does not explicitly mention that the tool is read-only or has no side effects. Additional transparency about safety or constraints would improve this.

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 well-structured with sections, front-loaded with the main purpose, and concise. Every sentence adds value without unnecessary repetition.

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

Completeness5/5

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

Given the tool's complexity (2 parameters, detailed output), the description comprehensively covers purpose, usage, and return structure. No obvious gaps are present.

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?

Schema coverage is 100% and descriptions are already in the schema. The description adds context about using the results for custom queries, but does not add significant semantic meaning beyond what the schema provides.

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's purpose: 'Get available search and return fields for an ENA result type.' This is a specific verb and resource, and it distinguishes from sibling tools like build_custom_query which uses these fields.

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 includes usage tips that explicitly mention using this before build_custom_query, providing context for when to use it. However, it does not state when not to use it or list alternative tools, so it's slightly incomplete.

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

get_download_urlsA

Get FTP download URLs for all sequencing data files in a study.

Usage Tips

Call after search_rna_studies() to get download URLs for selected studies. Returns FTP URLs that can be used with wget/curl or passed to generate_download_script().

Returns

dict Dictionary containing: - study_accession: Queried study - file_count: Total number of files - total_size_gb: Total download size in GB - runs: List of per-run file info, each with: - run_accession: Run identifier - file_count: Files in this run (2 for paired-end) - size_gb: Run size in GB - urls: List of FTP URLs (ftp://...) - md5_checksums: List of MD5 hashes (if include_md5=True) - message: Info message if no files found - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault
study_accessionYesStudy accession from search results. Accepts SRP/ERP/DRP or PRJNA/PRJEB/PRJDB formats
file_formatNoFile format to download (fastq, submitted, or sra). FASTQ is most commonfastq
include_md5NoInclude MD5 checksums for file integrity verification

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It details the return structure but does not explicitly state behavioral traits like safety (read-only), side effects, authentication needs, or rate limits. The return description hints at no destructive behavior, but this is not confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (usage tips, returns). It is informative and avoids unnecessary fluff, though the returns section repeats information that may be in the output schema. Slightly more concise could be achieved.

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

Completeness4/5

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

Given no annotations and the presence of output schema, the description covers inputs, usage, and outputs well. It mentions prerequisite (call after search) and provides detailed return structure. Lacks error handling details and authentication info, but is fairly complete.

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?

Schema coverage is 100%, so baseline is 3. The description does not add new meaning to parameters beyond the schema, though the return section mentions include_md5 affecting checksums. Overall, it does not significantly enhance parameter understanding.

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 gets FTP download URLs for sequencing data files in a study. It specifies the verb (get), resource (FTP download URLs), and scope (study). It implicitly distinguishes from siblings by mentioning usage after search_rna_studies and passing to generate_download_script.

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 explicitly says 'Call after search_rna_studies()' and mentions alternatives: 'can be used with wget/curl or passed to generate_download_script()'. While it doesn't explicitly list when not to use it, the guidance is clear and contextual.

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

get_result_typesA

Get all available result types (data categories) in ENA.

Usage Tips

Use to discover what types of data you can search for in the European Nucleotide Archive. Most users will use read_study or study for RNA-seq searches.

Returns

dict Dictionary containing: - count: Number of available result types - result_types: List of result types with id, description, primaryAccessionType, recordCount, lastUpdated - recommended_for_rna_studies: Recommended types for RNA studies - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description fully describes the return structure (dictionary with count, result_types, recommended_for_rna_studies, error). It implies a read-only query but does not explicitly state it is non-destructive. Good disclosure overall.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise with clear sections (description, Usage Tips, Returns). It is front-loaded with the main purpose. Some verbosity in section headers is acceptable.

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?

Despite no parameters, the tool's purpose is fully explained, and the return structure is detailed, complementing the output schema. The recommendation for RNA studies adds valuable context.

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 input schema has zero parameters, so the description correctly omits parameter details. Baseline for 0 params is 4.

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: 'Get all available result types (data categories) in ENA.' It specifies a specific verb ('get'), resource ('result types'), and scope ('all available'). This distinguishes it from sibling tools like search tools.

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

Usage Guidelines5/5

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

The 'Usage Tips' section explicitly says: 'Use to discover what types of data you can search for in the European Nucleotide Archive. Most users will use read_study or study for RNA-seq searches.' This provides clear usage context and mentions alternatives.

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

get_study_detailsA

Get comprehensive metadata for a specific ENA study including publications.

Usage Tips

Call after search_rna_studies() to verify a study matches your research needs before downloading. Returns detailed study description, publication links, and institutional metadata. Use this to check publications array for PubMed IDs.

Returns

dict Dictionary containing: - accession: Study accession - title: Brief study title - description: Detailed study description (full abstract/methods) - publications: List of publications with pubmed_id and source - center_name: Submitting institution - alias: Submitter's study name (often GSE accession for GEO) - data_type: Usually "STUDY" - status: "public" or "private" - first_public: Date made public (YYYY-MM-DD) - last_updated: Last modification date (YYYY-MM-DD) - file_report_links: Direct API links for file reports - error: Error message if study not found or if request fails

ParametersJSON Schema
NameRequiredDescriptionDefault
study_accessionYesStudy accession from search results. Accepts SRP/ERP/DRP or PRJNA/PRJEB/PRJDB formats

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description details the return structure but does not disclose any side effects, authentication needs, or rate limits. However, for a read-only 'get' operation, the transparency is adequate.

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?

Well-structured with clear sections: description, usage tips, returns. Every sentence adds value, and it is front-loaded with the purpose.

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

Completeness5/5

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

Given the single parameter, no annotations, and detailed return description, the tool definition is complete for its purpose. The description covers all necessary aspects.

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?

Input schema has 100% description coverage for the single parameter 'study_accession'. The description adds no additional semantics beyond the schema's description and examples.

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 it 'Get comprehensive metadata for a specific ENA study including publications.' It specifies the verb, resource, and scope, distinguishing it from siblings like 'get_study_publications' which only returns publications.

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?

Provides explicit usage tip: 'Call after search_rna_studies() to verify a study matches your research needs before downloading.' It also mentions checking publications array for PubMed IDs, giving clear context for when to use.

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

get_study_publicationsA

Get detailed publication information for a study from ENA and Europe PMC.

Usage Tips

Call after search_rna_studies() to get full publication metadata including author ORCID IDs, affiliations, citation counts, and full-text links. Enriches basic publication info from get_study_details() with complete bibliographic data from Europe PMC.

Returns

dict Dictionary containing: - accession: Study accession - publication_count: Number of publications found - publications: List of detailed publication objects, each with: - pubmed_id: PubMed ID - pmcid: PubMed Central ID (if available) - doi: Digital Object Identifier (if available) - title: Publication title - authors: List of author names - first_author: First author name - last_author: Last author name - author_details: Detailed author info with ORCID and affiliations - journal: Journal name - journal_issn: Journal ISSN - publication_year: Year published - publication_date: Full publication date - abstract: Publication abstract - citation_count: Times cited - is_open_access: Whether open access - in_epmc: Whether in Europe PMC - in_pmc: Whether in PubMed Central - has_pdf: Whether PDF available - full_text_urls: Available full text links - error: Error message if any

ParametersJSON Schema
NameRequiredDescriptionDefault
study_accessionYesStudy accession from search results. Accepts SRP/ERP/DRP or PRJNA/PRJEB/PRJDB formats

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description provides a detailed return structure covering all fields including author details, citation counts, and open access status. It implies read-only behavior by stating it 'gets' data from external sources. No destructive effects are mentioned, which is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a brief introductory sentence, a 'Usage Tips' section, and a detailed 'Returns' section. While fairly long, the detailed output documentation is necessary given no separate output schema. The information is front-loaded and each part serves a purpose.

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

Completeness4/5

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

The description covers the input parameter, usage context (after search_rna_studies), and a comprehensive return structure. It lacks explicit error handling details (though 'error' field is mentioned). Overall, it is quite complete for a tool with one parameter and no annotations.

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?

The single parameter 'study_accession' is well-documented in the input schema with description and examples. The tool description does not add additional semantics beyond what the schema already provides. Schema coverage is 100%, so baseline is 3.

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

Purpose5/5

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

The description clearly states the verb 'Get', the resource 'detailed publication information for a study', and the sources 'ENA and Europe PMC'. It differentiates from siblings like get_study_details by saying it enriches basic info with complete bibliographic data.

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?

Explicitly says to call after search_rna_studies() and that it enriches get_study_details(). This provides clear context for when to use the tool versus alternatives, though it does not state when not to use it.

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

list_library_typesA

List all available library strategies and sources for ENA searches.

Usage Tips

Use to discover available library types for filtering in search_rna_studies(). Returns all controlled vocabulary values for library_strategy and library_source. Call this before using the advanced library_strategies or library_sources parameters in search_rna_studies().

Returns

dict Dictionary with keys: - library_strategies: List of all strategies with "value" and "name" - library_sources: List of all sources with "value" and "name" - rna_strategies: Filtered list of RNA-related strategies only - summary: Counts of available options - usage_hint: How to use values in search_rna_studies()

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A5/5.0
Behavior5/5

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

Fully describes the return value structure (dict with five keys) and implies read-only behavior. No contradiction with missing annotations.

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?

Well-organized with sections, concise yet complete. Every sentence adds value.

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?

Complete for a zero-parameter tool: covers purpose, usage, output structure, and integration with sibling tool search_rna_studies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so description adds value by detailing the output schema and usage hints. Compensates fully for lack of parameters.

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?

Clearly states it lists all available library strategies and sources for ENA searches, with specific verb 'List' and resource. Distinguishes from siblings by mentioning use in search_rna_studies.

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?

Explicitly advises to call this before search_rna_studies to discover available types for filtering, and gives direct usage tips.

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

search_rna_studiesA

Search for RNA sequencing studies by disease, tissue, and organism.

When to use this tool: Primary search tool for finding RNA-seq datasets when you know the disease/condition OR tissue/cell-type you're interested in. Use search_studies_by_keywords() for broader searches by biological processes or methodology.

Default behavior: Searches across ALL organisms unless you specify one. This helps find relevant datasets across multiple species (human, mouse, rat, etc.).

Search tips:

  • Try different keyword variations if no results (e.g., "ALS" vs "amyotrophic lateral sclerosis")

  • Try broader terms (e.g., "neurodegeneration" instead of specific disease)

  • Search all organisms first (organism=None), then filter to specific species if needed

  • Use tissue parameter to narrow results to specific anatomical sites

Returns

dict Search results containing: - count: How many total studies match your search - returned: How many studies are in this response - studies: List of matching studies with titles, sample counts, and publication info - query_used: The exact search query that was executed - filters: What filters were applied to your search

ParametersJSON Schema
NameRequiredDescriptionDefault
diseaseNoDisease/condition keywords to search for (e.g., 'cancer', 'ALS'). Matched against disease and study_title fields
organismNoOrganism to search for. Use common names like 'human' or 'mouse', or scientific names like 'Homo sapiens'. Leave as None to search across all species
technologyNoRNA sequencing technology type: 'bulk' for standard RNA-Seq, 'single-cell' for scRNA-seq, 'small-rna' for miRNA/small RNA, 'ribo-seq' for ribosome profiling, 'rna-all' for any RNA technology. Set to None to search ALL RNA technologies without filtering
tissueNoTissue or cell type keywords to search for (e.g., 'brain', 'liver'). Matched against tissue_type and study_title fields
library_strategiesNoAdvanced: Specific sequencing strategies to filter by (e.g., ['RNA-Seq']). Overrides the technology preset. Call list_library_types() first to see all available options
library_sourcesNoAdvanced: Specific library source materials to filter by (e.g., ['TRANSCRIPTOMIC']). Overrides the technology preset. Call list_library_types() first to see all available options
limitNoHow many studies to return. Use 20 for initial searches, increase if needed. Set to 0 to get all results (up to system limits)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description fully explains default behavior (searches across all organisms unless specified) and gives search tips. It does not mention destructive actions (irrelevant for search) but adequately covers behavioral traits. The return structure is described. A score of 4 reflects good transparency without explicit safety or rate-limit details, which are not essential here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, when to use, default behavior, search tips, return format). It is somewhat verbose but each part adds value. Front-loading is effective. Slight reduction in redundancy would improve conciseness.

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

Completeness5/5

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

Given the complexity (7 parameters, 0 required, high schema coverage, and an output schema), the description is complete. It covers all essential aspects: purpose, usage context, behavioral details, parameter guidance, and return values. An agent can correctly invoke this tool based on the description alone.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining parameter roles (e.g., disease/tissue matched against study_title), clarifying the technology parameter vs library strategies, and providing search tips. This enhances understanding beyond the schema descriptions.

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's purpose: 'Search for RNA sequencing studies by disease, tissue, and organism.' It specifies the main parameters and distinguishes itself from the sibling tool search_studies_by_keywords, which is used for broader searches.

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

Usage Guidelines5/5

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

The description explicitly provides a 'When to use this tool' section, stating it is the primary search tool when you know disease/condition or tissue/cell-type, and directs to use search_studies_by_keywords() for broader searches by biological processes or methodology. This clearly differentiates usage from alternative tools.

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

search_studies_by_keywordsA

Search for studies using flexible keyword matching across titles and descriptions.

When to use this tool: Use this for broad exploratory searches when search_rna_studies() is too restrictive. Good for:

  • Searching by biological processes, pathways, or molecular mechanisms

  • Finding studies about specific genes, proteins, or complexes

  • Searching by methodology when you don't know the specific disease

  • General exploratory searches across many study types

Important notes:

  • Searches both study-level titles AND sample-level descriptions

  • Multi-word keywords are split: "breast cancer" searches for "breast" AND "cancer"

  • May return studies where only one sample mentions your keywords

  • Results can be broader than search_rna_studies() disease/tissue filters

Search tips:

  • Try keyword variations and abbreviations if no results (e.g., "immune response" vs "immunity")

  • Try broader or narrower terms (e.g., "transcription" vs "transcription factor binding")

  • Consider searching multiple organisms if limited results in one species

  • Use organism filter to narrow down results to specific species

Returns

dict Search results containing: - count: How many total studies match - returned: How many studies in this response - keywords_used: What keywords were searched - organism_filter: What organism filter was applied (if any) - studies: List of matching studies with accession, title, organism, and other metadata

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordsYesKeywords to search for in study titles and descriptions (e.g., 'immune response', 'transcription factor'). Multi-word phrases are automatically split into individual words that must all match
include_titleNoWhether to search in study titles (recommended: keep True)
include_descriptionNoWhether to search in study descriptions. This searches sample-level descriptions and may broaden results
organismNoOptionally filter by organism. Use common name like 'human' or scientific name like 'Homo sapiens'. Leave as None to search across all organisms
limitNoHow many studies to return. Start with 20, increase if needed

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Without annotations, the description fully discloses key behaviors: it searches both study titles and sample descriptions, splits multi-word keywords into AND conditions, may return studies with only one sample matching, and notes broader results compared to disease/tissue filters. This gives agents complete transparency.

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?

Well-structured with clear sections ('When to use', 'Important notes', 'Search tips') and a defined returns format. Every sentence is informative and earns its place. No redundancy.

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

Completeness5/5

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

Given the tool's complexity (5 parameters, 1 required, no enums, output schema present), the description is fully complete: it explains behavior, usage tips, parameter nuances, and the return structure. The output schema is described even though it's not required, adding clarity.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how multi-word keywords are handled (split into individual words that must all match), which is not in the schema. This extra context justifies a 4.

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's action ('Search for studies using flexible keyword matching across titles and descriptions') and distinguishes it from sibling tool search_rna_studies, making the purpose and differentiation explicit.

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?

Provides explicit when-to-use guidance ('Use this for broad exploratory searches when search_rna_studies() is too restrictive'), lists specific use cases, includes important notes on keyword splitting and search tips, and contrasts with alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 11 tool updatesv0.0.7
    • First observedbuild_custom_query
    • First observedfind_studies_by_publication
    • First observedgenerate_download_script
    • First observedget_available_fields
    • First observedget_download_urls
    • First observedget_result_types
    • First observedget_study_details
    • First observedget_study_publications
    • First observedlist_library_types
    • First observedsearch_rna_studies
    • First observedsearch_studies_by_keywords
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored across 11 tools

Disambiguation4/5

Tools are mostly distinct, with some overlap between metadata retrieval tools like get_available_fields and list_library_types, and between get_study_details and get_study_publications. However, clear descriptions clarify when to use each, reducing ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_rna_studies, get_study_details). Deviations like find_studies_by_publication still follow a predictable verb_noun_by_phrase structure.

Tool Count5/5

With 11 tools, the set is well-scoped for accessing the European Nucleotide Archive. Each tool serves a distinct purpose in the workflow: discovery, search, metadata retrieval, and download.

Completeness4/5

The tools cover the essential workflow from discovery to download. Minor gaps exist, such as the absence of direct date-based search and the find_studies_by_publication tool being a documented dead end, but these are acceptable for a read-only archive interface.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • SCMCP

    huang-sh
    A
    license
    C
    quality
    C
    maintenance
    An MCP server that enables single-cell RNA sequencing analysis through natural language, supporting data processing, visualization, and analysis tasks without requiring coding knowledge.
    52
    12
    BSD 3-Clause

  • SCMCP

    scmcphub
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that enables scRNA-Seq analysis through natural language, providing tools for data preprocessing, clustering, and biological visualization. It supports both predefined function execution and a flexible code mode powered by a Jupyter backend for automated single-cell transcriptomics workflows.
    16
    BSD 3-Clause

  • orphanet-link

    berntpopp
    A
    license
    A
    quality
    A
    maintenance
    An MCP server that enables querying rare-disease data from Orphanet, including disease nomenclature, cross-references, classifications, gene associations, HPO phenotypes, epidemiology, and natural history.
    19
    MIT