How do I use STRING-db MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@STRING-db MCP Server get interaction partners for insulin (INS) with confidence scores" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

STRING-db MCP Server

by Augmented-Nature

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Unofficial STRING MCP Server

A comprehensive Model Context Protocol (MCP) server for accessing the STRING protein interaction database. This server provides powerful tools for protein network analysis, functional enrichment, and comparative genomics through the STRING API.

Features

Tools (6 comprehensive tools)

get_protein_interactions: Get direct interaction partners for a specific protein with confidence scores and evidence types
get_interaction_network: Build and analyze protein interaction networks for multiple proteins
get_functional_enrichment: Perform functional enrichment analysis using GO terms, KEGG pathways, and other annotations
get_protein_annotations: Get detailed protein annotations and functional information
find_homologs: Find homologous proteins across different species for comparative analysis
search_proteins: Search for proteins by name or identifier across multiple species

Resources (6 resource templates)

string://network/{protein_ids}: Protein interaction network data for specified proteins
string://enrichment/{protein_ids}: Functional enrichment analysis results for protein sets
string://interactions/{protein_id}: Direct interaction partners for a specific protein
string://homologs/{protein_id}: Homologous proteins across different species
string://annotations/{protein_id}: Detailed protein annotations and functional information
string://species/{taxon_id}: Species-specific data and protein counts

Related MCP server: ProteinAtlas MCP Server

Installation

npm install
npm run build

Usage

With Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "string-server": {
      "command": "node",
      "args": ["/path/to/string-server/build/index.js"]
    }
  }
}

Example Queries

Find protein interactions:

Get interaction partners for insulin (INS) using get_protein_interactions

Build protein networks:

Build an interaction network for insulin signaling proteins: INS, INSR, IRS1, AKT1 using get_interaction_network

Functional enrichment analysis:

Perform functional enrichment analysis on these diabetes-related proteins: INS, INSR, IRS1, GLUT4, AKT1

Find protein homologs:

Find homologs of human insulin (INS) in mouse and rat using find_homologs

Search for proteins:

Search for insulin-related proteins using search_proteins with query "insulin"

Get protein annotations:

Get detailed annotations for insulin receptor pathway proteins using get_protein_annotations

Access resources directly:

Show me the resource string://network/INS,INSR,IRS1

API Integration

This server integrates with the STRING Database API (https://string-db.org/):

STRING REST API: For protein interaction data, annotations, and homology information
Multi-species support: Over 5000 organisms supported
Evidence types: Neighborhood, fusion, cooccurrence, coexpression, experimental, database, textmining
Confidence scoring: Interaction confidence scores from 0-1000

Key Features

Protein Interaction Analysis

Direct interactions: Find immediate interaction partners
Network construction: Build comprehensive interaction networks
Evidence classification: 7 types of interaction evidence
Confidence scoring: Quantitative interaction confidence

Functional Analysis

GO enrichment: Gene Ontology term enrichment
KEGG pathways: Metabolic and signaling pathway analysis
Custom backgrounds: Use custom protein sets as background
Statistical significance: P-values and FDR correction

Comparative Genomics

Cross-species analysis: Find homologs across organisms
Evolutionary relationships: Analyze protein evolution
Species filtering: Focus on specific taxonomic groups
Ortholog identification: Distinguish orthologs from paralogs

Network Properties

Topology analysis: Network density, clustering, connectivity
Hub identification: Find highly connected proteins
Module detection: Identify protein complexes and modules
Path analysis: Find shortest paths between proteins

Complementary Servers

This STRING server works excellently with:

UniProt MCP Server: For protein sequences and detailed functional annotations
PDB MCP Server: For protein structures and structural analysis
AlphaFold MCP Server: For predicted protein structures

Together, these provide comprehensive protein analysis: Sequence → Structure → Interactions → Function

Data Quality & Validation

Curated data: STRING combines curated databases with computational predictions
Evidence integration: Multiple evidence types combined using probabilistic framework
Regular updates: Database updated regularly with new experimental data
Quality scores: Each interaction has associated confidence scores

Error Handling

The server includes robust error handling for:

Invalid protein identifiers
Network connectivity issues
API rate limiting
Species validation
Parameter validation
Malformed requests

Development

# Install dependencies
npm install

# Build the server
npm run build

# Run in development mode
npm run dev

Attribution

This project is developed by Augmented Nature 🌐 Website: augmentednature.ai

About STRING Database: STRING is a database of known and predicted protein-protein interactions. The interactions include direct (physical) and indirect (functional) associations; they stem from computational prediction, from knowledge transfer between organisms, and from interactions aggregated from other (primary) databases.

Citation

If you use this project in your research or publications, please cite it as follows:

author = {Moudather Chelbi},
title = {STRING DB MCP Server},
year = {2025},
howpublished = {https://github.com/Augmented-Nature/STRING-db-MCP-Server},
note = {Accessed: 2025-06-29}

Available Tools

6 tools

find_homologsC

Find homologous proteins across different species

ParametersJSON Schema

Name	Required	Description
`protein_id`	Yes	Protein identifier (gene name, UniProt ID, or STRING ID)
`species`	No	Source species name or NCBI taxonomy ID (default: 9606 for human)
`target_species`	No	Target species to search for homologs (optional)

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 what the tool does but reveals nothing about performance characteristics (e.g., speed, accuracy), data sources, limitations (e.g., coverage gaps), or what the output looks like (format, structure). For a bioinformatics tool with potentially complex behavior, this is insufficient.

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 gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters documented elsewhere and follows good front-loading principles.

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 homology search (which involves algorithms, databases, and potential limitations) and the absence of both annotations and an output schema, the description is incomplete. It doesn't help an agent understand what to expect from the tool's behavior or results, which is particularly important for scientific tools where accuracy and methodology matter.

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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain what constitutes a 'homolog', how homology is determined, or format examples). Baseline 3 is appropriate when 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 action ('Find') and resource ('homologous proteins across different species'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'search_proteins' or 'get_protein_annotations', but the focus on cross-species homology is specific enough for basic understanding.

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 'search_proteins' or 'get_protein_annotations'. It doesn't mention prerequisites, limitations, or typical use cases, leaving the agent to infer usage from the tool name alone.

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

get_functional_enrichmentC

Perform functional enrichment analysis on a set of proteins

ParametersJSON Schema

Name	Required	Description
`protein_ids`	Yes	List of protein identifiers
`species`	No	Species name or NCBI taxonomy ID (default: 9606 for human)
`background_string_identifiers`	No	Background protein set for enrichment (optional)

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 what 'functional enrichment analysis' entails (e.g., statistical methods, output format, computational cost, or potential side effects like data processing time). This is a significant gap for a tool with no structured safety or behavior hints.

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's appropriately sized and front-loaded, making it easy for an agent 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 complexity of 'functional enrichment analysis' (a bioinformatics task with statistical implications), no annotations, and no output schema, the description is incomplete. It fails to explain what the analysis returns, how results are structured, or any prerequisites (e.g., valid protein ID formats), leaving critical gaps for effective tool 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 schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain what 'functional enrichment' means in terms of the parameters or how they interact). 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 action ('perform functional enrichment analysis') and target ('on a set of proteins'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_protein_annotations' or 'search_proteins', which might also involve protein analysis but for different purposes.

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 sibling tools like 'get_protein_annotations' for annotation retrieval or 'search_proteins' for querying, leaving the agent to infer usage based on context alone.

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

get_interaction_networkC

Build and analyze protein interaction network for multiple proteins

ParametersJSON Schema

Name	Required	Description
`protein_ids`	Yes	List of protein identifiers
`species`	No	Species name or NCBI taxonomy ID (default: 9606 for human)
`network_type`	No	Type of network to build (default: functional)
`add_nodes`	No	Number of additional interacting proteins to add (default: 0)
`required_score`	No	Minimum interaction confidence score (0-1000, default: 400)

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 full burden for behavioral disclosure. It mentions 'build and analyze' which implies computational processing, but doesn't disclose important traits like computational intensity, timeout risks, data source limitations, or what 'analyze' specifically entails (e.g., returns network statistics, visualizations, or raw edges). For a network construction tool with 5 parameters, this leaves significant behavioral gaps.

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 perfectly concise - a single sentence that states the core purpose without any redundant words. It's front-loaded with the essential action ('build and analyze') and resource ('protein interaction network'). Every word earns its place, making it easy for an agent 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 complexity of network construction/analysis, 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'analyze' produces (network properties? visualization? edge list?), doesn't mention data sources or limitations, and provides no context about computational requirements. For a tool that likely returns complex network data, this leaves too many unknowns.

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 no parameter-specific information beyond what's in the schema - it doesn't explain relationships between parameters (e.g., how 'add_nodes' interacts with 'required_score') or provide usage examples. With complete schema coverage, baseline 3 is appropriate as the description doesn't enhance parameter understanding.

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 tool's purpose with specific verbs ('build and analyze') and resource ('protein interaction network for multiple proteins'). It distinguishes from sibling tools like 'get_protein_interactions' by emphasizing network construction and analysis rather than just retrieving interactions. However, it doesn't explicitly differentiate from all siblings like 'get_functional_enrichment' which might also involve network analysis.

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 sibling tools like 'get_protein_interactions' (which might retrieve individual interactions) or 'get_functional_enrichment' (which might analyze network properties). There's no context about prerequisites, typical use cases, or limitations that would help an agent choose between available options.

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

get_protein_annotationsC

Get detailed annotations and functional information for proteins

ParametersJSON Schema

Name	Required	Description	Default
`protein_ids`	Yes	List of protein identifiers
`species`	No	Species name or NCBI taxonomy ID (default: 9606 for human)

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 what the tool does but lacks details on traits like whether it's read-only, potential rate limits, authentication needs, or what 'detailed annotations' entail in terms of output format or data scope. This is inadequate 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 is front-loaded and appropriately sized, 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 complexity of protein annotation retrieval, no annotations, and no output schema, the description is insufficient. It does not explain what 'detailed annotations' include, how results are structured, or any limitations (e.g., maximum protein IDs). This leaves significant gaps for an AI agent to use the tool effectively.

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 schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description does not add any additional meaning beyond the schema, such as explaining the format of protein identifiers or species names. Baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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 action ('Get') and resource ('detailed annotations and functional information for proteins'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'search_proteins' or 'get_functional_enrichment', which might also involve protein information retrieval, so it lacks sibling distinction.

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 such as 'search_proteins' or 'get_interaction_network'. It does not mention prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on tool names alone.

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

get_protein_interactionsC

Get direct interaction partners for a specific protein

ParametersJSON Schema

Name	Required	Description
`protein_id`	Yes	Protein identifier (gene name, UniProt ID, or STRING ID)
`species`	No	Species name or NCBI taxonomy ID (default: 9606 for human)
`limit`	No	Maximum number of interactions to return (default: 10)
`required_score`	No	Minimum interaction confidence score (0-1000, default: 400)

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 'direct interaction partners' but doesn't specify data sources, rate limits, authentication needs, error handling, or what constitutes a 'direct' interaction. For a tool with 4 parameters and no output schema, this leaves significant behavioral gaps.

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, focused sentence with zero wasted words. It's appropriately sized for a straightforward query tool and front-loads the core purpose without unnecessary elaboration.

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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain return values, data formats, error conditions, or how parameters interact (e.g., how 'species' affects 'protein_id' resolution). For a biological data query tool, 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 all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying the tool focuses on 'direct' interactions, which might relate to the 'required_score' parameter. This meets the baseline for high schema coverage.

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 the resource 'direct interaction partners for a specific protein', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_interaction_network' or 'search_proteins', which might offer overlapping functionality.

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 'get_interaction_network' or 'search_proteins'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.

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

search_proteinsC

Search for proteins by name or identifier across species

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (protein name, gene name, or identifier)
`species`	No	Species name or NCBI taxonomy ID (optional)
`limit`	No	Maximum number of results (default: 10)

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 search functionality but lacks details on permissions, rate limits, pagination, or what the results look like (e.g., format, fields). For a search tool with zero annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, 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 complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain result formats, error handling, or behavioral traits, leaving gaps that could hinder effective tool invocation by an AI agent.

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 (query, species, limit) with descriptions and constraints. The description adds minimal value by implying the search scope ('across species') but doesn't provide additional syntax or usage details beyond what the schema offers, aligning with the baseline for high coverage.

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 action ('Search for proteins') and the resource ('by name or identifier across species'), making the purpose evident. However, it doesn't explicitly differentiate this tool from sibling tools like 'find_homologs' or 'get_protein_annotations', which might also involve protein-related searches or queries, so it doesn't fully achieve sibling distinction.

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 'find_homologs' or 'get_protein_annotations'. It mentions searching 'across species', which implies a broad scope, but doesn't specify exclusions or recommend other tools for specific scenarios, leaving the agent with little context for selection.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some potential confusion between get_interaction_network (analyzes networks for multiple proteins) and get_protein_interactions (gets direct partners for a specific protein), which could overlap in use cases. Otherwise, tools like find_homologs, get_functional_enrichment, and search_proteins are clearly differentiated.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case, such as find_homologs, get_functional_enrichment, and search_proteins. This uniformity makes the tool set predictable and easy to navigate for agents.

Tool Count5/5

With 6 tools, this server is well-scoped for a protein database domain, covering key operations like search, annotation, interaction analysis, and homology without being overwhelming. The count aligns well with typical MCP server ranges for focused functionality.

Completeness4/5

The tool set covers essential protein database operations, including search, annotation, interaction analysis, and functional enrichment, but lacks explicit CRUD operations like create, update, or delete proteins, which might be intentional for a read-only database. Minor gaps exist, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

String Db B
io.github.pipeworx-io
STRING protein-protein interaction networks across ~12k organisms
Bioinformatics Biology & Medicine
362
STRING Database MCP Server A
org.string-db
Query STRING interactions, enrichment, annotations, homology, and PPI networks.
Bioinformatics Biology & Medicine
1725
Uniprot A
io.github.pipeworx-io
UniProt MCP — protein sequence + function database.
Bioinformatics Biology & Medicine Research & Data
372
Complex Portal A
io.github.pipeworx-io
EBI Complex Portal MCP.
Bioinformatics Biology & Medicine
332

Related MCP Servers

Ensembl MCP Server
Biology & Medicine Research & Data
Augmented-Nature
F
license
A
quality
D
maintenance
A comprehensive Model Context Protocol (MCP) server that provides access to the Ensembl REST API for genomic data, comparative genomics, and biological annotations.
Updated 8 months ago (2025-12-21 10:09 UTC)
19
3
ProteinAtlas MCP Server
Biology & Medicine Research & Data
Augmented-Nature
F
license
A
quality
D
maintenance
A comprehensive Model Context Protocol (MCP) server for accessing Human Protein Atlas data, providing information about protein expression, subcellular localization, pathology, and more.
Updated 8 months ago (2025-12-21 10:10 UTC)
16
4
STRING-MCP
Bioinformatics Research & Data Biology & Medicine
MCPmed
A
license
B
quality
D
maintenance
A Model Context Protocol server that provides tools for interacting with the STRING database to analyze protein-protein interaction networks and functional enrichment. It enables users to map protein identifiers, retrieve interaction data, and generate biological network visualizations through natural language interfaces.
Updated a year ago (2025-07-28 14:50 UTC)
11
3
BSD 3-Clause
protein-mcp-server
Biology & Medicine Bioinformatics
cyanheads
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server providing programmatic access to 3D protein structural data from RCSB PDB, PDBe, and UniProt, enabling search, retrieval, comparison, and analysis of protein structures.
Updated 3 days ago (2026-08-30 22:07 UTC)
269
5
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Augmented-Nature/STRING-db-MCP-Server'

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