Official STRING Database MCP Server

Overview Schema Source Related Servers Discussions Admin

STRING: Protein–protein interaction (PPI) enrichment

string_ppi_enrichment

Test whether a protein set has more interactions than expected by chance, reporting edge counts and a p-value for network enrichment.

Instructions

This tool tests if your network is enriched in protein-protein interactions compared to the background proteome-wide distribution (i.e., if your proteins are more functionally connected than expected by chance).

The enrichment is assessed using the actual observed edges versus expected edges in a random network of the same size.
The p-value reflects the likelihood that your observed number of interactions would occur by chance.
Report the p-value as a human-readable value (e.g. 2.3e-5 or 0.023).

When calling related tools use the same input parameters unless otherwise specified.

Output fields:

number_of_nodes: Number of proteins in your network
number_of_edges: Number of observed edges/interactions
average_node_degree: Mean degree (average number of interactions per node)
local_clustering_coefficient: Average clustering coefficient in the network
expected_number_of_edges: Expected number of edges in a random network of the same size
p_value: p-value for network enrichment (smaller = more enriched)

Example identifiers: "SMO%0dTP53"

Input Schema

TableJSON Schema

Name	Required	Description
`species`	No	NCBI/STRING taxon (e.g. 9606 for human, or STRG0AXXXXX for uploaded genomes).
`identifiers`	Yes	One or more protein identifiers, separated by %0d.
`required_score`	No	Minimum interaction confidence score. Omit unless a confidence threshold is requested or a broader/narrower threshold is needed.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.13.0Sep 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it explains the statistical model (observed vs. expected edges in a random network of the same size) and what the p-value means. It does not cover caveats such as minimum network size, behavior on sparse inputs, or permissions, so it is not exhaustive.

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

Conciseness4/5

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

Front-loaded with a clear one-line purpose, followed by tightly organized bullets for mechanics, p-value, and reporting. However, the enumerated output fields duplicate the existing output schema, so that block does not fully earn its place per the rule that return values need not be explained when an output schema exists.

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

Completeness4/5

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

For a 3-parameter tool with a full output schema, the description supplies purpose, method, example identifier, and reporting guidance, which is sufficient to call it correctly. It is only missing sibling-oriented routing (e.g., vs. string_network_clustering) to be fully complete.

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

Parameters3/5

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

Schema coverage is 100%, so all three parameters are already documented in the schema. The description adds little beyond one example identifier ('SMO%0dTP53') and the convention hint about reusing parameters; it does not clarify format or semantics beyond the schema, so the baseline of 3 applies.

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

Purpose5/5

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

States a specific verb and resource: it 'tests if your network is enriched in protein-protein interactions compared to the background proteome-wide distribution.' The scope (structural connectivity vs. chance) distinguishes it from term-based siblings like string_enrichment and string_functional_annotation without needing their schemas.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer you call this when you have a protein set and want to know if it is more connected than expected. There is no explicit when-to-use, when-not, or named alternative among siblings such as string_network_clustering. The note 'use the same input parameters when calling related tools' is a convention hint, not selection guidance.

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

Deploy Server