Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@STRING-MCP show me the interaction network for human proteins TP53 and BRCA1"
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.
A comprehensive Python package for interacting with the STRING database API through a Model Context Protocol (MCP) bridge.
Install the package in development mode:
pip install -e .Or install from PyPI (when available):
pip install string-mcpRelated MCP server: STRING-db MCP Server
"mcpServers": {
"string-mcp": {
"command": "/path/to/python/env/bin/string-mcp-server",
"env": {}
}
}
}The package provides an MCP server for integration with MCP-compatible clients:
# Run the MCP server
string-mcp-serverThe MCP server provides the following tools:
map_identifiers: Map protein identifiers to STRING IDs
get_network_interactions: Get network interactions data
get_functional_enrichment: Perform functional enrichment analysis
get_network_image: Generate network visualization images
get_version_info: Get STRING database version information
The package also provides a string-mcp command for standalone usage:
# Run demo
string-mcp demo
# Get help
string-mcp --help
# Map protein identifiers
string-mcp map TP53 BRCA1 EGFR --species 9606
# Get network interactions
string-mcp network TP53 BRCA1 --species 9606
# Generate network image
string-mcp image TP53 BRCA1 --output network.png --species 9606from stringmcp.main import StringDBBridge
# Initialize the bridge
bridge = StringDBBridge()
# Map protein identifiers
proteins = ["TP53", "BRCA1", "EGFR"]
mapped = bridge.map_identifiers(proteins, species=9606) # 9606 = human
# Get network interactions
interactions = bridge.get_network_interactions(proteins, species=9606)
# Perform functional enrichment
enrichment = bridge.get_functional_enrichment(proteins, species=9606)Protein Identifier Mapping: Convert various protein identifiers to STRING IDs
Network Analysis: Retrieve protein-protein interaction networks
Functional Enrichment: Perform gene ontology and pathway enrichment analysis
Network Visualization: Generate network images in various formats
Interaction Partners: Find all interaction partners for proteins
Functional Annotations: Get detailed functional annotations
Protein Similarity: Calculate similarity scores between proteins
PPI Enrichment: Test for protein-protein interaction enrichment
MCP Integration: Full Model Context Protocol server implementation
map_identifiers(): Map protein identifiers to STRING IDs
get_network_interactions(): Get network interaction data
get_network_image(): Generate network visualization images
get_interaction_partners(): Find all interaction partners
get_functional_enrichment(): Perform enrichment analysis
get_functional_annotation(): Get functional annotations
get_protein_similarity(): Calculate similarity scores
get_ppi_enrichment(): Test for PPI enrichment
get_version_info(): Get STRING database version
The package uses a StringConfig class for configuration:
from stringmcp.main import StringConfig, StringDBBridge
config = StringConfig(
base_url="https://string-db.org/api",
version_url="https://version-12-0.string-db.org/api",
caller_identity="my_app",
request_delay=1.0 # Delay between requests in seconds
)
bridge = StringDBBridge(config)The package supports multiple output formats:
JSON: Structured data (default)
TSV: Tab-separated values
XML: XML format
IMAGE: Network visualization images
SVG: Scalable vector graphics
PSI_MI: PSI-MI format
The package supports all species available in STRING. Common species IDs:
Human: 9606
Mouse: 10090
Rat: 10116
Yeast: 4932
E. coli: 511145
To use the MCP server with an MCP client, configure it as follows:
{
"mcpServers": {
"string-mcp": {
"command": "string-mcp-server",
"env": {}
}
}
}The server will automatically handle:
JSON-RPC communication
Tool discovery and invocation
Error handling and reporting
Base64 encoding for image data
# Install in development mode with dev dependencies
pip install -e .[dev]
# Format code
black stringmcp/
# Type checking
mypy stringmcp/
# Lint code
flake8 stringmcp/Note: Test files are not currently included in this repository. To add tests, create a tests/ directory and add test files following the pytest configuration in pyproject.toml.
STRINGmcp/
├── pyproject.toml # Package configuration and dependencies
├── README.md # This file
├── LICENSE # MIT License
├── .gitignore # Git ignore patterns
├── stringmcp/ # Main package
│ ├── __init__.py # Package initialization
│ └── main.py # Core STRING API bridge and MCP server
└── string_mcp.egg-info/ # Package metadata (generated during install)
├── PKG-INFO # Package information
├── SOURCES.txt # Source files list
├── dependency_links.txt
├── entry_points.txt # CLI entry points
├── requires.txt # Dependencies
└── top_level.txt # Top-level package namesMIT License - see LICENSE file for details.
Fork the repository
Create a feature branch
Make your changes
Add tests
Run the test suite
Submit a pull request
For issues and questions, please use the GitHub issue tracker.
This example demonstrates the comprehensive functionality of the STRING-DB MCP bridge by analyzing a set of well-known human DNA repair proteins: TP53, BRCA1, BRCA2, ATM, and ATR.
Map gene symbols to STRING identifiers:
[
{
"queryIndex": 0,
"queryItem": "TP53",
"stringId": "9606.ENSP00000269305",
"ncbiTaxonId": 9606,
"taxonName": "Homo sapiens",
"preferredName": "TP53",
"annotation": "Cellular tumor antigen p53; Acts as a tumor suppressor in many tumor types; induces growth arrest or apoptosis depending on the physiological circumstances and cell type..."
},
{
"queryIndex": 1,
"queryItem": "BRCA1",
"stringId": "9606.ENSP00000418960",
"ncbiTaxonId": 9606,
"taxonName": "Homo sapiens",
"preferredName": "BRCA1",
"annotation": "Breast cancer type 1 susceptibility protein; E3 ubiquitin-protein ligase that specifically mediates the formation of 'Lys-6'-linked polyubiquitin chains..."
},
{
"queryIndex": 2,
"queryItem": "BRCA2",
"stringId": "9606.ENSP00000369497",
"ncbiTaxonId": 9606,
"taxonName": "Homo sapiens",
"preferredName": "BRCA2",
"annotation": "Breast cancer type 2 susceptibility protein; Involved in double-strand break repair and/or homologous recombination..."
},
{
"queryIndex": 3,
"queryItem": "ATM",
"stringId": "9606.ENSP00000278616",
"ncbiTaxonId": 9606,
"taxonName": "Homo sapiens",
"preferredName": "ATM",
"annotation": "Serine-protein kinase ATM; Serine/threonine protein kinase which activates checkpoint signaling upon double strand breaks..."
},
{
"queryIndex": 4,
"queryItem": "ATR",
"stringId": "9606.ENSP00000343741",
"ncbiTaxonId": 9606,
"taxonName": "Homo sapiens",
"preferredName": "ATR",
"annotation": "Serine/threonine-protein kinase ATR; Serine/threonine protein kinase which activates checkpoint signaling upon genotoxic stresses..."
}
]Examine network interactions between these proteins:
[
{
"stringId_A": "9606.ENSP00000269305",
"stringId_B": "9606.ENSP00000369497",
"preferredName_A": "TP53",
"preferredName_B": "BRCA2",
"score": 0.995
},
{
"stringId_A": "9606.ENSP00000269305",
"stringId_B": "9606.ENSP00000343741",
"preferredName_A": "TP53",
"preferredName_B": "ATR",
"score": 0.996
},
{
"stringId_A": "9606.ENSP00000269305",
"stringId_B": "9606.ENSP00000278616",
"preferredName_A": "TP53",
"preferredName_B": "ATM",
"score": 0.999
},
{
"stringId_A": "9606.ENSP00000269305",
"stringId_B": "9606.ENSP00000418960",
"preferredName_A": "TP53",
"preferredName_B": "BRCA1",
"score": 0.999
},
{
"stringId_A": "9606.ENSP00000278616",
"stringId_B": "9606.ENSP00000369497",
"preferredName_A": "ATM",
"preferredName_B": "BRCA2",
"score": 0.995
},
{
"stringId_A": "9606.ENSP00000278616",
"stringId_B": "9606.ENSP00000418960",
"preferredName_A": "ATM",
"preferredName_B": "BRCA1",
"score": 0.999
},
{
"stringId_A": "9606.ENSP00000278616",
"stringId_B": "9606.ENSP00000343741",
"preferredName_A": "ATM",
"preferredName_B": "ATR",
"score": 0.999
},
{
"stringId_A": "9606.ENSP00000343741",
"stringId_B": "9606.ENSP00000369497",
"preferredName_A": "ATR",
"preferredName_B": "BRCA2",
"score": 0.831
},
{
"stringId_A": "9606.ENSP00000343741",
"stringId_B": "9606.ENSP00000418960",
"preferredName_A": "ATR",
"preferredName_B": "BRCA1",
"score": 0.996
},
{
"stringId_A": "9606.ENSP00000369497",
"stringId_B": "9606.ENSP00000418960",
"preferredName_A": "BRCA2",
"preferredName_B": "BRCA1",
"score": 0.999
}
]Key Findings: All interactions show very high confidence scores (>0.8), with most exceeding 0.99, indicating these proteins form a tightly interconnected functional module.
Check if this network is significantly enriched for interactions:
{
"number_of_nodes": 5,
"number_of_edges": 10,
"average_node_degree": 4.0,
"local_clustering_coefficient": 1.0,
"expected_number_of_edges": 5,
"p_value": 0.0122
}Statistical Significance: The network shows perfect clustering (coefficient = 1.0) and is significantly enriched for interactions (p = 0.0122), with twice as many edges as expected by chance.
Analyze which biological pathways are enriched in this protein set:
Top DNA Repair Pathways (Selected Results):
[
{
"category": "Process",
"term": "GO:0071479",
"number_of_genes": 5,
"preferredNames": ["TP53", "ATM", "ATR", "BRCA2", "BRCA1"],
"p_value": 9.72e-13,
"fdr": 1.52e-08,
"description": "Cellular response to ionizing radiation"
},
{
"category": "Process",
"term": "GO:0042770",
"number_of_genes": 5,
"preferredNames": ["TP53", "ATM", "ATR", "BRCA2", "BRCA1"],
"p_value": 1.69e-11,
"fdr": 1.32e-07,
"description": "Signal transduction in response to DNA damage"
},
{
"category": "Process",
"term": "GO:0006281",
"number_of_genes": 5,
"preferredNames": ["TP53", "ATM", "ATR", "BRCA2", "BRCA1"],
"p_value": 1.05e-08,
"fdr": 1.10e-05,
"description": "DNA repair"
},
{
"category": "KEGG",
"term": "hsa03440",
"number_of_genes": 3,
"preferredNames": ["ATM", "BRCA2", "BRCA1"],
"p_value": 8.34e-08,
"fdr": 2.80e-05,
"description": "Homologous recombination"
},
{
"category": "KEGG",
"term": "hsa04115",
"number_of_genes": 3,
"preferredNames": ["TP53", "ATM", "ATR"],
"p_value": 5.27e-07,`
"fdr": 5.44e-05,`
"description": "p53 signaling pathway"
}
]Disease Associations:
[
{
"category": "DISEASES",
"term": "DOID:1612",
"number_of_genes": 4,
"preferredNames": ["TP53", "ATM", "BRCA2", "BRCA1"],
"p_value": 5.72e-10,
"fdr": 2.02e-06,
"description": "Breast cancer"
},
{
"category": "DISEASES",
"term": "DOID:3012",
"number_of_genes": 3,
"preferredNames": ["TP53", "BRCA2", "BRCA1"],
"p_value": 6.59e-10,
"fdr": 2.02e-06,
"description": "Li-Fraumeni syndrome"
}
]The package can generate protein interaction network visualizations showing evidence-based functional associations.
Example Network Visualization: View Protein Interaction Network
This visualization shows the protein-protein interaction network for TP53, BRCA1, BRCA2, ATM, and ATR with high-confidence interactions (score ≥ 400).
The package can also create enrichment scatter plots showing the most significantly enriched biological processes.
Example Enrichment Visualization: View Functional Enrichment Plot
This visualization displays the top 10 most significantly enriched biological processes and pathways for the DNA repair protein set, showing p-values and gene counts for each enriched term.
This comprehensive analysis demonstrates that the STRING-DB MCP bridge successfully:
Identified all 5 DNA repair proteins with detailed annotations
Discovered 10 high-confidence protein interactions (all >0.8 score)
Revealed significant pathway enrichments with p-values < 1e-8
Confirmed statistical significance of the network (p = 0.0122)
Generated both network and enrichment visualizations
The results validate these proteins as a core DNA damage response module, with exceptionally strong enrichment for:
Cellular response to ionizing radiation (p = 1.52e-8)
DNA damage signaling (p = 1.32e-7)
Homologous recombination (p = 2.8e-5)
p53 signaling pathway (p = 5.44e-5)
Breast cancer associations (p = 2.02e-6)v This showcases the complete functionality of the STRING-DB MCP bridge for protein interaction network analysis and functional annotation.
Return URL of enrichment scatter figure
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | Yes | NCBI/STRING taxon (required) | |
| category | No | Enrichment category (default: Process) | |
| group_by_similarity | No | Group terms by similarity | |
| color_palette | No | Color palette for visualization | |
| number_of_term_shown | No | Maximum number of terms to show | |
| x_axis | No | X-axis parameter | |
| highres | No | High resolution image (default: false) | |
| svg | No | Vector graphic format (SVG) | |
| download_image | No | Download image to local file |
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 only states the output (URL) without describing what the tool does (e.g., generates a visualization, requires computation, may have rate limits, or returns a static vs. dynamic URL). For a tool with 10 parameters and no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness for the given information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what an 'enrichment scatter figure' is, how parameters affect the output, or what the returned URL represents (e.g., a temporary link, file format). For a visualization tool with many options, more context 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.
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 10 parameters with descriptions like 'Protein list' and 'NCBI/STRING taxon (required)'. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or default behaviors. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return URL of enrichment scatter figure' states the action (return URL) and resource (enrichment scatter figure), but is vague about what an 'enrichment scatter figure' represents. It doesn't differentiate from siblings like 'get_network_image' or 'get_functional_enrichment', leaving the specific purpose unclear beyond basic verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or exclusions, and doesn't mention sibling tools like 'get_functional_enrichment' or 'get_ppi_enrichment' that might be related. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all functional annotations for proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| allow_pubmed | No | Include PubMed annotations (default: false) | |
| only_pubmed | No | Return only PubMed annotations (default: false) |
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 retrieving annotations but doesn't specify aspects like rate limits, authentication needs, data format, or potential side effects. This is a significant gap for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral traits, usage context, or output details, leaving gaps that could hinder an agent's ability to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters well. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters (e.g., how 'allow_pubmed' and 'only_pubmed' relate). 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('functional annotations for proteins'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_functional_enrichment' or 'get_enrichment_figure', which might retrieve related but different data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_functional_enrichment' or other sibling tools. It lacks context about prerequisites or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform GO / pathway enrichment on a protein set.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| background_identifiers | No | Background proteome for enrichment analysis |
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 the type of analysis ('GO/pathway enrichment') but lacks details on computational requirements, rate limits, output format, or error handling. This is inadequate for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of enrichment analysis, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, usage context, or result interpretation, leaving significant gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters well. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain what 'GO/pathway enrichment' entails or how parameters interact), resulting in the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('perform') and the resource ('GO/pathway enrichment on a protein set'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_ppi_enrichment' or 'get_enrichment_figure' that might perform similar enrichment analyses, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_ppi_enrichment' or 'get_enrichment_figure', nor does it mention prerequisites or exclusions. It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get homology information for proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) |
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 but only states the basic action without details on permissions, rate limits, response format, or error handling. It doesn't add meaningful context beyond the obvious, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on output, error cases, or how it fits with siblings, leaving the agent with gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema fully documents both parameters ('identifiers' and 'species'). The description doesn't add any semantic details beyond what's in the schema, such as example identifiers or species usage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('homology information for proteins'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_homology_best' or 'get_functional_annotation', which likely handle related protein data, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_homology_best' or 'get_functional_annotation', which appear to be related siblings. It lacks any context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get best homology matches for proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | Source species NCBI/STRING taxon | |
| species_b | No | Target species list for homology search |
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 tool retrieves matches but doesn't describe what 'best' entails (e.g., criteria like score thresholds), output format, rate limits, or error handling. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place in conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of homology matching, 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, output, and usage context, leaving significant gaps for an agent to understand how to effectively invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (identifiers, species, species_b). The description adds no additional meaning beyond implying homology matching, which is already inferred from the tool name. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('best homology matches for proteins'), making the purpose immediately understandable. It distinguishes from the sibling 'get_homology' by specifying 'best' matches, though it doesn't fully explain what makes them 'best' versus the sibling's approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_homology' or other sibling tools. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve interaction partners for given proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| limit | No | Maximum number of partners to return | |
| required_score | No | Interaction confidence score threshold (0-1000) | |
| network_type | No | Type of interactions |
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 but provides minimal information. It mentions 'retrieve' which implies a read operation, but doesn't address rate limits, authentication requirements, error conditions, response format, or whether this is a query against a database or computational prediction. The description lacks essential behavioral context for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a retrieval tool and front-loads the core functionality without unnecessary preamble or elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'interaction partners' means in this context, what data source is being queried, what format the results will be in, or provide any examples. The combination of missing behavioral context and lack of output information creates significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so 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 how identifiers should be formatted, what the interaction partners represent, or provide 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'interaction partners for given proteins', making the purpose understandable. It distinguishes from some siblings like 'get_homology' or 'get_version_info' by focusing on protein interactions, but doesn't explicitly differentiate from 'get_network_interactions' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_network_interactions' and 'get_ppi_enrichment' that likely handle similar protein interaction data, there's no indication of when this specific retrieval tool is preferred or what distinguishes it from other interaction-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return URL of STRING network image
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| highres | No | High resolution image (default: true) | |
| svg | No | Vector graphic format (SVG) | |
| network_type | No | Network type (default: functional) | |
| network_flavor | No | Style of edges (default: evidence) | |
| required_score | No | Threshold of significance (0-1000) | |
| add_color_nodes | No | Adds color nodes based on scores to input proteins | |
| add_white_nodes | No | Adds white nodes based on scores (added after color nodes) | |
| download_image | No | Download image to local file |
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 but offers minimal information. It states the tool returns a URL but doesn't describe what happens with that URL, whether the image is generated dynamically or cached, any rate limits, authentication requirements, or error conditions. For a tool with 10 parameters and no annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just 5 words: 'Return URL of STRING network image.' Every word earns its place by specifying the action, output format, and resource type. There's zero waste or redundancy, and the core purpose is communicated immediately without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'STRING network image' represents visually, how the URL can be used, what format the image returns in (beyond SVG parameter), or any limitations of the service. The agent must rely entirely on parameter schemas without contextual understanding of the tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly with descriptions, enums, and defaults. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return URL of STRING network image' specifies both the verb ('return URL') and the resource ('STRING network image'). It distinguishes from siblings like 'get_enrichment_figure' or 'get_network_interactions' by focusing specifically on image generation rather than data retrieval or analysis. However, it doesn't explicitly differentiate from potential image-related siblings beyond the STRING context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this image generation tool should be preferred over data-focused siblings like 'get_network_interactions' or 'get_interaction_partners', nor does it specify prerequisites or contextual constraints. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve STRING interaction edges.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| required_score | No | Interaction confidence score threshold (0-1000) | |
| add_nodes | No | Number of additional nodes to add | |
| network_type | No | Type of interactions |
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 only states the action ('Retrieve') without details on permissions, rate limits, output format, or side effects. For a tool with 5 parameters and no output schema, this is insufficient to inform safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, output expectations, and differentiation from siblings, leaving significant gaps for an agent to understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Retrieve') and resource ('STRING interaction edges'), providing a basic purpose. However, it lacks specificity about what 'interaction edges' are (e.g., protein-protein interactions) and doesn't distinguish this tool from siblings like 'get_interaction_partners' or 'get_ppi_enrichment', leaving the scope vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions, such as how it differs from 'get_interaction_partners' or 'get_ppi_enrichment', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get protein-protein interaction enrichment statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| required_score | No | Interaction confidence score threshold (0-1000) |
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 only states what the tool does without mentioning permissions, rate limits, output format, or other behavioral traits like whether it's read-only or has side effects. This is inadequate for a tool with parameters and no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output expectations, and usage context, which are crucial for an agent to effectively invoke this tool without structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the parameters. The description does not add any additional meaning beyond what the schema provides, such as explaining the significance of 'enrichment statistics' or how parameters interact. 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.
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 'protein-protein interaction enrichment statistics', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_functional_enrichment' or 'get_interaction_partners', which might offer related but distinct functionalities, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools such as 'get_functional_enrichment' and 'get_interaction_partners' available, there is no indication of context, prerequisites, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current STRING database version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states this is a read operation ('Return'), which implies it's non-destructive, but doesn't disclose any behavioral traits like rate limits, authentication needs, or what the return value looks like (e.g., format, structure). This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It states what the tool does but lacks context on usage, behavioral details, or output format, making it minimally viable but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly doesn't mention any parameters, which is appropriate, earning a high score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and resource ('current STRING database version'), making the purpose unambiguous. However, it doesn't differentiate this tool from its siblings (like get_functional_annotation or get_homology), which all appear to retrieve different types of STRING data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map protein identifiers to STRING IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Protein list | |
| species | No | NCBI/STRING taxon (e.g. 9606 for human) | |
| echo_query | No | Echo query identifiers in response | |
| limit | No | Limit number of results |
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 only states the basic function without mentioning any behavioral traits such as rate limits, authentication needs, error handling, or what happens if mapping fails. For a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with a single, clear sentence: 'Map protein identifiers to STRING IDs.' There is no wasted text, and it efficiently communicates the core purpose without unnecessary details, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of mapping identifiers (which could involve errors or partial matches), no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like, how results are structured, or any edge cases. This lack of context makes it inadequate for a tool that likely returns structured data, leaving the agent with insufficient information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, the schema already documents all parameters well (e.g., 'identifiers' as 'Protein list', 'species' as 'NCBI/STRING taxon'). The baseline score of 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance understanding of parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Map protein identifiers to STRING IDs.' It specifies the action ('Map') and the resource ('protein identifiers'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_homology' or 'get_interaction_partners', which might also involve protein identifiers but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, nor does it refer to sibling tools. This lack of usage context makes it harder for an AI agent to decide when this tool is appropriate compared to others in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_enrichment_figureget_functional_annotationget_functional_enrichmentget_homologyget_homology_bestget_interaction_partnersget_network_imageget_network_interactionsget_ppi_enrichmentget_version_infomap_identifiersMost tools have clearly distinct purposes, such as get_functional_annotation for annotations and get_network_interactions for edges. However, get_homology and get_homology_best could be confused, as both retrieve homology information with only subtle differences in scope.
All tools follow a consistent verb_noun pattern with 'get_' or 'map_' prefixes, such as get_enrichment_figure and map_identifiers. There are no deviations in naming conventions, making the set highly predictable and readable.
With 11 tools, the count is well-scoped for a protein interaction and enrichment analysis server. Each tool appears to serve a specific, non-redundant function, fitting within the typical 3-15 tool range for such domains.
The tool set covers core protein analysis workflows, including enrichment, homology, interactions, and identifier mapping. A minor gap exists in lacking update or delete operations, but this is reasonable for a retrieval-focused database server, and agents can work around this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
STRING protein-protein interaction networks across ~12k organisms
Query STRING interactions, enrichment, annotations, homology, and PPI networks.
Protein research over UniProtKB — search by function, fetch curated records, map IDs, proteomes.
Knowledge graph ingestion, entity search, ontology analysis, and CoPass scoring.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MCPmed/STRINGmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
