Skip to main content
Glama
mfiume

Omics AI MCP Server

by mfiume
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Omics AI MCP Server

A Model Context Protocol (MCP) server that enables AI agents to conversationally interact with Omics AI Explorer networks for genomics research and data analysis.

Overview

This MCP server wraps the functionality of the omics-ai-python-library to provide AI agents with seamless access to genomics data across multiple Omics AI Explorer networks including:

  • HiFi Solves (hifisolves.org) - Long-read sequencing data

  • Neuroscience AI (neuroscience.ai) - Neuroscience genomics data

  • ASAP (cloud.parkinsonsroadmap.org) - Aligning Science Across Parkinson's

  • Viral AI (viral.ai) - Viral genomics and surveillance data

  • Target ALS (dataportal.targetals.org) - ALS research data

Related MCP server: snowflake-mcp

Features

The MCP server provides the following tools for AI agents:

  • list_collections - Discover available data collections in any network

  • list_tables - Browse tables within specific collections

  • get_schema_fields - Examine table schemas and field types

  • query_table - Query data with filters, pagination, and ordering

  • count_rows - Count rows matching specific criteria

  • sql_search - Execute direct SQL queries using Trino syntax

Installation

git clone https://github.com/mfiume/omics-ai-mcp.git
cd omics-ai-mcp
npm install

Usage

Running the Server

npm start

Configuration for Claude Desktop

Add to your Claude Desktop configuration file:

{
  "mcpServers": {
    "omics-ai": {
      "command": "node",
      "args": ["src/index.js"],
      "cwd": "/path/to/omics-ai-mcp"
    }
  }
}

Example AI Agent Interactions

Once configured, AI agents can conversationally query genomics data:

Agent: "What collections are available on the Viral AI network?"

User: "Show me the tables in the virusseq collection"

Agent: "List the first 10 variants from the variants table where chromosome equals chr1"

User: "How many total variants are in the VirusSeq database?"

Tool Reference

list_collections

Lists all available collections in a network.

Parameters:

  • network (required): Network name (hifisolves, viral, neuroscience, etc.) or full URL

  • access_token (optional): Authentication token

list_tables

Lists all tables in a specific collection.

Parameters:

  • network (required): Network name or URL

  • collection_slug (required): Collection identifier (e.g., "virusseq", "gnomad")

  • access_token (optional): Authentication token

get_schema_fields

Retrieves the schema and field definitions for a table.

Parameters:

  • network (required): Network name or URL

  • collection_slug (required): Collection identifier

  • table_name (required): Qualified table name (e.g., "collections.virusseq.variants")

  • access_token (optional): Authentication token

query_table

Queries data from a table with optional filtering and pagination.

Parameters:

  • network (required): Network name or URL

  • collection_slug (required): Collection identifier

  • table_name (required): Qualified table name

  • filters (optional): Filter criteria object

  • limit (optional): Max rows to return (default: 100)

  • offset (optional): Rows to skip (default: 0)

  • order_by (optional): Sort specification

  • access_token (optional): Authentication token

count_rows

Counts rows matching specified filters.

Parameters:

  • network (required): Network name or URL

  • collection_slug (required): Collection identifier

  • table_name (required): Qualified table name

  • filters (optional): Filter criteria object

  • access_token (optional): Authentication token

sql_search

Executes direct SQL queries against a collection using Trino syntax with enhanced result formatting.

Parameters:

  • network (required): Network name or URL

  • collection_slug (required): Collection identifier

  • sql (required): SQL query string (use Trino syntax with double quotes for identifiers)

  • max_polls (optional): Maximum number of polling attempts (default: 10)

  • poll_interval (optional): Seconds to wait between polls (default: 2.0)

  • access_token (optional): Authentication token

Features:

  • Automatic async query polling with robust error handling

  • Intelligent result formatting (table view for simple data, JSON for complex)

  • Progress indicators and pagination info

  • Timeout management for long-running queries

Example queries:

  • SELECT COUNT(*) FROM "schema"."table"

  • SELECT * FROM "schema"."variants" WHERE chrom = 'chr1' LIMIT 10

  • SELECT DISTINCT chrom FROM "schema"."variants" ORDER BY chrom

Supported Networks

The server supports these pre-configured networks (use short names for convenience):

Short Name

Full URL

Description

hifisolves

hifisolves.org

Long-read sequencing data

neuroscience

neuroscience.ai

Neuroscience genomics

asap

cloud.parkinsonsroadmap.org

Parkinson's research

viral

viral.ai

Viral genomics

targetals

dataportal.targetals.org

ALS research

Error Handling

The server includes robust error handling for:

  • Network connectivity issues

  • Authentication failures

  • Invalid parameters

  • API response parsing errors

  • Timeout handling for long-running queries

Development

# Development mode with auto-restart
npm run dev

# Production mode
npm start

License

MIT License - see LICENSE file for details.

Related Projects

Available Tools

6 tools
count_rowsC

Count the number of rows matching given filters

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork name or URL
collection_slugYesCollection slug name
table_nameYesQualified table name
filtersNoDictionary of filters to apply
access_tokenNoOptional access token for authentication

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions 'matching given filters' which implies filtering behavior, but doesn't disclose authentication needs (though 'access_token' parameter hints at it), rate limits, performance characteristics, error conditions, or what the return value looks like (just a count number or structured response).

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 a single, efficient sentence with zero wasted words. It's appropriately sized for a counting operation and front-loads the core functionality immediately.

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

Completeness2/5

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

For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format (e.g., integer count, JSON structure), error handling, authentication requirements, or how filters work with the table context. The schema handles parameter documentation, but behavioral aspects are largely missing.

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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema by implying that 'filters' parameter is used for matching rows, but doesn't provide additional syntax, format details, or examples beyond what the schema provides.

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

Purpose4/5

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

The description clearly states the verb ('Count') and resource ('rows'), specifying that it counts rows matching given filters. It distinguishes from siblings like 'query_table' or 'sql_search' by focusing on counting rather than retrieving data, but doesn't explicitly differentiate from them in the description text.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'query_table' or 'sql_search', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.

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

get_schema_fieldsC

Get the schema fields for a specific table

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork name or URL
collection_slugYesCollection slug name
table_nameYesQualified table name (e.g., 'collections.gnomad.variants')
access_tokenNoOptional access token for authentication

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe what 'schema fields' include (e.g., column names, types, constraints), whether authentication is required (though 'access_token' is optional in schema), or any rate limits or errors. This leaves significant gaps for a tool with no annotation coverage.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format (e.g., JSON structure of schema fields), potential errors, or usage context relative to siblings. For a tool with no structured output or behavioral hints, more detail is needed to guide effective use.

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 description coverage is 100%, so the input schema already documents all parameters well. The description doesn't add meaning beyond this, such as explaining relationships between parameters (e.g., how 'network', 'collection_slug', and 'table_name' combine to identify the table). Baseline 3 is appropriate as the schema handles the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('schema fields for a specific table'), making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'list_tables' or 'query_table', which might also involve schema-related operations, so it lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing to know the table name from 'list_tables', or contrast it with siblings like 'query_table' for data retrieval versus schema inspection.

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

list_collectionsC

List all collections available in an Omics AI Explorer network

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork name (hifisolves, neuroscience, asap, viral, targetals) or full URL
access_tokenNoOptional access token for authentication

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it lists collections but doesn't mention if this is a read-only operation, requires authentication, has rate limits, or what the output format looks like (e.g., pagination, error handling). This leaves significant gaps for an agent to understand how to invoke it safely and effectively.

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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized, making it easy to parse and understand quickly.

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

Completeness2/5

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

Given the complexity of a list operation with authentication parameters and no output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, response format, or error handling, which are crucial for an agent to use this tool correctly in context with its siblings.

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 input schema has 100% description coverage, clearly documenting both parameters ('network' and 'access_token') with examples and requirements. The description adds no additional meaning beyond this, such as explaining parameter interactions or constraints, so it meets the baseline for adequate but not enhanced parameter semantics.

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

Purpose4/5

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

The description clearly states the verb 'List' and the resource 'collections available in an Omics AI Explorer network', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_tables', which might list different resources in the same network, leaving some ambiguity about uniqueness.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'list_tables' or 'query_table'. It lacks context about prerequisites, such as network selection, or exclusions, making it unclear how it fits into the broader toolset.

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

list_tablesC

List all tables in a specific collection

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork name or URL
collection_slugYesCollection slug name (e.g., 'gnomad', 'virusseq')
access_tokenNoOptional access token for authentication

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions (e.g., whether 'access_token' is required for certain networks), output format (e.g., list of table names or full metadata), pagination, or error handling. This leaves significant gaps for a tool with authentication parameters.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does, making it easy to parse and understand quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It does not explain what the output looks like (e.g., a list of table names, JSON objects), how authentication works with the 'access_token', or potential limitations (e.g., rate limits, network-specific behaviors). For a tool with authentication and multiple parameters, more context is needed.

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 description coverage is 100%, so the schema already documents all three parameters ('network', 'collection_slug', 'access_token') with clear descriptions. The description adds no additional meaning beyond implying the tool operates within a collection, which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('tables in a specific collection'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'list_collections' or 'get_schema_fields', which might list different resources or provide schema details instead of table names.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that 'list_collections' should be used first to find collections, or that 'get_schema_fields' is for table details rather than listing tables. There is no context on prerequisites or exclusions.

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

query_tableC

Query data from a table with optional filters and pagination

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork name or URL
collection_slugYesCollection slug name
table_nameYesQualified table name
filtersNoDictionary of filters to apply
limitNoMaximum number of rows to return (default: 100)
offsetNoNumber of rows to skip (default: 0)
order_byNoOrdering specification
access_tokenNoOptional access token for authentication

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional filters and pagination but fails to cover critical aspects like authentication needs (implied by 'access_token' parameter), rate limits, error handling, or return format. For a query tool with 8 parameters, this leaves significant gaps in understanding how the tool behaves in practice.

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 a single, efficient sentence that front-loads the core purpose ('Query data from a table') and briefly mentions key features ('optional filters and pagination'). There is no wasted verbiage, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's complexity (8 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain authentication requirements, result format, error conditions, or how to interpret parameters like 'filters' or 'order_by'. For a data query tool, this leaves too many operational questions unanswered.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by hinting at filters and pagination but doesn't provide additional context beyond what's in the schema (e.g., how filters work, pagination defaults). Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Query') and resource ('data from a table'), specifying the core action. It distinguishes from siblings like 'count_rows' or 'get_schema_fields' by focusing on data retrieval rather than metadata or aggregation. However, it doesn't explicitly differentiate from 'sql_search', which might also query data, leaving some ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'sql_search' or 'list_tables'. It mentions optional filters and pagination but doesn't specify use cases, prerequisites, or exclusions. This lack of context makes it challenging for an AI agent to choose between sibling tools effectively.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedcount_rows
    • First observedget_schema_fields
    • First observedlist_collections
    • First observedlist_tables
    • First observedquery_table
    • First observedsql_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: counting rows, retrieving schema fields, listing collections, listing tables, querying tables, and executing SQL queries. The descriptions clearly differentiate their functions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., count_rows, get_schema_fields, list_collections, list_tables, query_table, sql_search). The naming is uniform and predictable throughout the set.

Tool Count5/5

With 6 tools, the set is well-scoped for an Omics AI data exploration server. Each tool serves a specific and necessary function, covering core operations without being overly sparse or bloated.

Completeness4/5

The toolset provides comprehensive coverage for data querying and exploration, including listing, querying, and schema inspection. A minor gap exists in data manipulation (e.g., insert/update/delete operations), but the core workflows for analytics are well-supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • GenomeMCP

    Eldergenix
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to query clinical genomics databases, retrieve supporting literature, analyze population genetics, and visualize biological pathways.
    19
    MIT

  • snowflake-mcp

    faressoft
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to execute SQL queries and explore Snowflake databases using natural language, with schema discovery, table inspection, and readonly mode.
    11
    679
    MIT

  • Databricks MCP Server

    proxziima
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to explore Unity Catalog metadata, execute SQL queries, and analyze data lineage including notebooks and jobs, empowering autonomous data discovery and query generation in Databricks.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mfiume/omics-ai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server