Skip to main content
Glama

STRING Database MCP Server

STRING: Functional enrichment analysis

string_enrichment

This tool retrieves functional enrichment for a set of proteins using STRING.

  • If queried with a single protein, the tool expands the query to include the protein’s 10 most likely interactors; enrichment is performed on this set, not the original single protein.

  • For two or more proteins, enrichment is performed on the exact input set.

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

  • Focus summaries on the top categories and most relevant terms for the results. Always report FDR for each claim.

  • Report FDR as a human-readable value (e.g. 2.3e-5 or 0.023).

  • IMPORTANT: Remember to suggest showing an enrichment graph for a specific category of user interest (e.g., GO, KEGG)

  • Very large responses are capped while preserving category diversity.

  • Use expand_category to return only one category with expanded term coverage and per-term gene details.

  • If a row has preferredNames_omitted: true, do not infer which proteins are in that term from the returned rows. Use string_functional_annotation with the same proteins/species and detail_for_term set to the exact term ID.

Output fields (per enriched term):

  • category: Term category (e.g., GO Process, KEGG pathway)

  • term: Enriched term (GO ID, domain, or pathway)

  • number_of_genes: Number of input genes with this term

  • number_of_genes_in_background: Number of background genes with this term

  • ncbiTaxonId: NCBI taxon ID

  • preferredNames: Canonical protein names, only when the full per-term list is short enough to show

  • proteinCount: Number of proteins matching this term

  • preferredNames_omitted: True when the gene list was omitted instead of showing a misleading partial list

  • p_value: Raw p-value

  • fdr: False Discovery Rate (B-H corrected p-value)

  • description: Description of the enriched term

Response metadata:

  • input_gene_name_mapping: Only included when displayed gene lists contain submitted identifiers that differ from STRING preferred names.

  • category_summary: Total and returned term counts per category; use expand_category for categories where truncated is true or where the user wants deeper category-specific detail.

  • truncated_categories / omitted_categories: Categories with terms not shown in the current response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
speciesNo
proteinsYesRequired. One or more protein identifiers, separated by %0d. Example: SMO%0dTP53
expand_categoryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It extensively discloses key behaviors: single-protein expansion to interactors, capping of large responses, omitted gene lists with preferredNames_omitted, category truncation, and FDR reporting requirements. This goes far beyond typical descriptions and gives the agent critical expectations for invoking and interpreting results.

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

Conciseness4/5

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

The description is long but well-organized with bullet points and separate sections for behavior, output fields, and metadata. It front-loads the core purpose and immediately follows with execution nuances. While each sentence adds value, the length is substantial; however, given the tool's complexity, the structure earns a high score for clarity and organization.

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

Completeness5/5

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

For a complex enrichment tool with output schema and multiple edge cases, the description is exceptionally complete. It covers parameter behavior, output field semantics, metadata handling, and cross-tool hints. An agent has enough information to invoke correctly and interpret the response accurately, even without annotations.

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

Parameters3/5

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

The input schema already includes descriptions for all three parameters (proteins, species, expand_category), though the context reports only 33% coverage, suggesting the schema descriptions may be minimal. The tool description adds meaningful semantics for proteins (single vs. multiple sets) and expand_category (expanded coverage, category selection), but does not add extra meaning for the species parameter beyond its schema description. It partially compensates for low schema coverage, but not fully.

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

Purpose5/5

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

The description clearly states the tool's function: 'retrieves functional enrichment for a set of proteins using STRING.' This is a specific verb+resource pairing that distinguishes it from siblings like string_functional_annotation, which provides annotations rather than enrichment. The detailed behavior notes further clarify its unique role among the sibling tools.

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?

The description provides clear context on how the tool behaves (single vs. multiple proteins, expand_category usage) but does not explicitly state when to prefer this tool over alternatives. It mentions 'When calling related tools, use the same input parameters' but lacks direct comparison or exclusionary guidance like 'use X instead.' Thus, usage intent is implied rather than explicitly differentiated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Several tool pairs have overlapping purposes: string_network_link and string_visual_network both return network URLs with nearly identical behavior, and string_all_interaction_partners vs string_interactions_query_set both query interactions, differing subtly in scope. The enrichment/annotation tools also share boundaries, making it difficult for agents to disambiguate without reading detailed descriptions.

Naming Consistency3/5

All tools share the 'string_' prefix, but the pattern is inconsistent: some are verb-first (create_file, resolve_proteins), some are noun-first (interactions_query_set, network_link), and some are bare nouns (enrichment, homology). This mixed convention reduces predictability.

Tool Count4/5

At 17 tools, the server is slightly above the ideal range, but it covers a broad domain: interactions, networks, enrichment, annotation, homology, species resolution, and sequence search. The count is justified by the complexity of the STRING database.

Completeness4/5

The tool set covers core STRING workflows: querying interactions, constructing networks, computing enrichment, retrieving annotations, identifying homologs, mapping IDs, and exporting data. Minor gaps exist (e.g., direct edge-list tables and intricate interaction score details), but the overall surface is robust.