Skip to main content
Glama

STRING Database MCP Server

by org.string-db

STRING: Retrieve proteins associated with a functional term

string_proteins_for_term

Retrieve proteins annotated with a functional term or descriptive text in a single species.
You can query for tissues, compartments, diseases, processes, pathways, and domains.

IMPORTANT: For cross-species comparisons, run this tool separately for each species.
Select relevant model organisms to search or ask user to provide the selection. The results reflect annotation depth within each category; use caution when interpreting.

If no results are found, try simplifying the query.
For tissue queries, follow BRENDA tissue nomenclature and omit the word "tissue"
(e.g. use "skin" instead of "skin tissue").

Output fields:

  • category: Source database of the matched functional term (e.g. GO, KEGG, Reactome, Pfam, InterPro).

  • term: Exact identifier for the functional term.

  • description: The free text description of the term.

  • proteinCount: Number of proteins annotated with that term

  • preferredNames: Full protein-name list when detail_for_term is set

  • stringIds: STRING protein identifiers when returned

  • preferredNames_omitted: True when a row omits the protein-name list

  • stringIds_omitted: True when STRING identifiers are omitted

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
speciesNoNCBI/STRING taxonomy ID. This tool only supports one species per call. It cannot return results across multiple species or identify the species with the most/fewest proteins. For such questions, run this tool separately for each species and then compare the results. Default is 9606 (human). Examples: 10090 for mouse, or STRG0AXXXXX for uploaded genomes.9606
term_textYesRequired. Functional term identifier (GO, KEGG, Reactome, etc.) or descriptive free text (e.g. 'hsa05218', 'Melanoma', 'GO:0008543', 'Fibroblast growth factor').
detail_for_termNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and does so excellently. It discloses the single-species limitation, the inability to compare across species, the caveat that results reflect annotation depth, the tissue-naming convention, and details about output fields including omission flags. This goes well beyond basic read/write 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 well-structured with a front-loaded main sentence, concise usage notes, and a clear output-field list. Every sentence earns its place, and the formatting makes it easy to scan. It is appropriately sized for the tool's complexity.

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?

The description is complete for this tool's complexity: it explains query types, single-species restrictions, search tips, caveats, and output semantics. Even though an output schema exists, the description provides additional context that helps the agent anticipate results and edge cases.

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

Parameters5/5

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

Although the schema already covers 67% of parameters, the description adds essential semantics: term_text accepts both identifiers and free text with concrete examples, detail_for_term is tied to the output fields and omission behavior, and species examples are provided. This compensation makes the parameter behavior fully understandable.

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 opening sentence clearly states the tool's action: 'Retrieve proteins annotated with a functional term or descriptive text in a single species.' The verb 'retrieve' and the resource 'proteins associated with a functional term' are specific, and it distinguishes itself from siblings by emphasizing the single-species scope and the broad range of queryable term types.

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

Usage Guidelines4/5

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

The description provides strong usage guidance: it lists queryable categories, instructs users to run the tool separately for cross-species comparisons, advises simplifying queries when no results are found, and specifies BRENDA tissue nomenclature. It does not explicitly name alternative sibling tools, so it stops short of a perfect 5.

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

All STRING Database MCP Server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources