STRING Database MCP Server
Server Details
Query STRING interactions, enrichment, annotations, homology, and PPI networks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 17 of 17 tools scored. Lowest: 2.6/5.
Most tools have clearly distinct purposes (e.g., enrichment vs. functional annotation vs. homology). However, the network-related tools (string_interactions_query_set, string_network_link, string_visual_network) overlap in retrieving interaction data, differing only in output format. Also, string_interaction_evidence and string_interactions_query_set could cause confusion. Overall, the distinctions are mostly clear.
The naming convention is mostly 'string_' + verb_noun (e.g., string_create_file, string_resolve_proteins). However, there are inconsistencies: string_proteins_for_term uses noun_verb order, string_help is a single word, and some use singular vs. plural (interaction_evidence vs. interactions_query_set). The pattern is recognizable but not perfectly consistent.
With 17 tools, the count is slightly above the typical ideal range (3-15) but still reasonable for a comprehensive analysis server. Each tool serves a distinct function in the STRING workflow, and no tool feels redundant. The scope is well-scoped for the complexity of protein interaction analysis.
The tool set covers the key workflows: species lookup, protein resolution, sequence search, interactions, networks, enrichment, clustering, homology, functional annotation, evidence retrieval, and file export. Minor gaps exist, such as lack of network comparison or direct download of full data tables, but the core functionalities are present and well-integrated.
Available Tools
17 toolsstring_all_interaction_partnersSTRING: Get all interaction partners for proteinsAInspect
Retrieves all interaction partners for one or more proteins from STRING.
This tool returns all known interactions between your query protein(s) and any other proteins in the STRING database.
Use this when asking “What does TP53 interact with?”
It differs from the
networktool, which only shows interactions within the input set or a limited extension of it.If the user refers to "physical interactions", "complexes", or "binding", set the network type to "physical".
You can filter for strong interactions using required_score.
Evidence scores:
nscore(neighborhood),fscore(fusion),pscore(phylogenetic profile),
ascore(coexpression),escore(experimental),dscore(database),tscore(text mining)
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| identifiers | Yes | Required. One or more protein identifiers, separated by carriage return (%0d). Example: TP53%0dSMO | |
| network_type | No | ||
| required_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it returns all known interactions with any proteins, not just input set. Explains evidence scores (nscore, fscore, etc.). However, does not mention rate limits or any destructive behavior (though read-only, this is implied but not explicit). Still, good behavioral context.
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?
Well-structured with bullet points for evidence scores and clear sections. Not overly long, but evidence score details could be more concise. Front-loaded with main purpose and use case. Every sentence adds value.
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?
Output schema exists, so return values not needed. Description covers purpose, usage, parameter semantics, and behavioral details. For a retrieval tool, it is complete and leaves little ambiguity. No gaps identified.
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 coverage is only 25% (low). Description adds meaning: explains identifiers format (carriage return), purpose of required_score for filtering, and network_type for physical interactions. Species parameter is minimally explained. Compensates for low schema coverage with useful parameter insights.
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?
Description states 'Retrieves all interaction partners for one or more proteins from STRING'. Specific verb 'retrieves' and clear resource 'interaction partners'. Distinguishes from sibling 'network' tool by explaining difference: 'returns all known interactions...any other proteins' vs 'only shows interactions within the input set'.
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?
Explicitly states when to use: 'What does TP53 interact with?' and provides alternative when not: 'differs from the network tool...'. Also gives guidance for physical interactions and filtering with required_score. Clear context for when to set network_type to 'physical'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_create_fileSTRING: Create a downloadable STRING result fileAInspect
Creates a downloadable file for STRING-derived results.
Use this tool when the user explicitly asks to download, save, export, or receive a file containing STRING data, tables, protein lists, enrichment results, networks, etc.
When a response would otherwise include a publication-style or supplementary result table, or another table clearly intended for reuse outside chat, mention that a downloadable TSV/CSV file can be generated on request. Ask whether they want the file, unless they already requested it. Do not create the file until the user asks for it.
Do not store unrelated data or full conversation transcripts.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Required STRING-derived file content. For .tsv/.csv: one rectangular table, one header row, matching delimiter, no Markdown/prose/repeated headers/multiple tables. Use one row per entity, edge, cluster member, annotation, or enrichment term. Use bare numeric scores/FDR/p-values; put interpretation and caveats in chat or .md/.txt. | |
| filename | Yes | Required. Suggested output filename with a safe extension such as .tsv, .csv, .json, .md, or .txt. Match content to the extension; prefer .tsv for reusable tabular STRING data. Use a concise name that reflects the STRING analysis result, for example string-enrichment.tsv. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It implies file creation but does not detail side effects like file overwrite, persistence, or permissions. It does note content restrictions, which helps 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?
Description is multi-paragraph but each sentence adds necessary context. Front-loads core purpose. Slightly verbose but well-organized with clear sections.
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?
Covers when to use, parameter expectations, and restrictions. Output schema exists to explain return values. Completeness is adequate for a file creation tool with clear instructions.
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 coverage is 100% with detailed descriptions. The description adds value by specifying content format requirements (TSV/CSV structure), filename conventions, and delimiter usage, enhancing understanding beyond schema.
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 creates a downloadable file for STRING-derived results, using specific verbs ('Creates', 'downloadable') and resource type ('file'), and it distinguishes from sibling analysis tools by focusing on export.
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?
Provides explicit guidance: use when user asks to download/save/export; mentions alternatives (no need until asked); warns against storing unrelated data or transcripts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_enrichmentSTRING: Functional enrichment analysisAInspect
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_categoryto 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. Usestring_functional_annotationwith the same proteins/species anddetail_for_termset 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_categoryfor categories wheretruncatedis true or where the user wants deeper category-specific detail.truncated_categories / omitted_categories: Categories with terms not shown in the current response.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein identifiers, separated by %0d. Example: SMO%0dTP53 | |
| expand_category | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: single protein expansion, response capping, output fields, response metadata, and instructions for handling omitted gene lists. No contradictions.
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?
Well-structured with bullet points and clear sections, but slightly verbose with agent-oriented instructions (e.g., 'Focus summaries', 'IMPORTANT'). Length is justified by complexity but could be trimmed.
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?
Covers input behavior, output fields, metadata, and edge cases. Even without an output schema, the description lists all return fields and response metadata, making it highly complete for a complex tool.
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 significant meaning beyond the input schema: explains how the proteins parameter behaves for single vs multiple inputs, and clarifies the expand_category parameter's purpose. Schema already has descriptions, but description enriches them.
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 it retrieves functional enrichment for a set of proteins using STRING. It distinguishes behavior for single vs multiple proteins, setting it apart from sibling tools like string_ppi_enrichment.
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?
Provides explicit when-to-use instructions: single protein expansion, using expand_category for deeper detail, and calling string_functional_annotation when preferredNames_omitted is true. Missing explicit when-not comparisons with all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_enrichment_image_urlSTRING: Get enrichment result figure (image URL)CInspect
Retrieves the STRING enrichment figure image URL for a set of proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| x_axis | No | ||
| species | No | ||
| category | No | ||
| identifiers | Yes | Required. Protein identifiers, separated by %0d. Example: SMO%0dTP53 | |
| color_palette | No | ||
| group_by_similarity | No | ||
| number_of_terms_shown | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 fails to disclose any behavioral traits such as idempotency, authentication needs, rate limits, error handling, or what the URL points to. The output schema may partially compensate, but it is not visible in the provided context.
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 sentence, which is concise, but it lacks structure and omits critical information. While it wastes no words, it is too brief to be fully useful. An ideal description would be equally concise but more informative.
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 complexity (7 parameters, 1 required), low schema coverage, and no annotations, the description is severely incomplete. It does not explain how to use the tool, what the URL represents, or what to expect in the output. An output schema exists but is not shown, and the description should compensate.
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 very low (14%), yet the tool description does not explain any parameters. It only mentions 'a set of proteins' which hints at the required identifiers parameter but provides no details on how to format or use it. The description adds no value beyond the schema.
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 retrieves a STRING enrichment figure image URL for a set of proteins. It uses a specific verb ('retrieves') and resource ('STRING enrichment figure image URL'), distinguishing it from siblings like string_enrichment (data) and string_visual_network (network images).
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 implies usage when an enrichment figure image URL is needed, but provides no explicit guidance on when to use this tool vs. alternatives (e.g., string_enrichment for raw data) or when not to use it. With many sibling tools, more comparative context would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_functional_annotationSTRING: Retrieve functional annotations for proteinsAInspect
This tool retrieves curated functional annotations for a set of proteins.
Each input protein is mapped to known biological terms from ontologies, pathway databases, tissues, compartments and domains — such as Gene Ontology (GO), KEGG, and UniProt Keywords.
Use this when the user asks what a protein does, where it's localized, expressed, or which pathways it participates in.
Keep the output short and focused by highlighting a few diverse and specific annotations for each protein.
This tool does not perform statistical enrichment — use the enrichment tool for that.
Output fields (per protein):
stringId: STRING protein identifier
preferredName: Gene name or alias
annotation: Functional description or keyword
category: Source category (e.g. GO, KEGG, Keyword)
term: Functional term or ID
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| identifiers | Yes | Separate multiple protein queries by %0d. e.g. SMO%0dTP53 | |
| detail_for_term | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output fields and advises keeping output brief. It also explains the detail_for_term parameter for handling truncated results. However, it does not disclose whether results are paginated or if there are limits.
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?
Well-structured with paragraphs and bullet points. Front-loaded with purpose. Every sentence contributes value without redundancy.
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 3 parameters and output schema provided, the description covers purpose, usage, behavior, and output fields. It also explains a special parameter use case. No obvious gaps.
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 coverage appears high from visible descriptions, but context signal says 33%. The description adds extra meaning for identifiers (separator %0d) and detail_for_term (when to use), going beyond schema. Baseline 3 adjusted up for added value.
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 it retrieves functional annotations for proteins, mapping to biological terms like GO, KEGG. It distinguishes from sibling tools like string_enrichment by noting what it does not do.
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?
Explicitly states when to use (when user asks what a protein does, localization, pathways) and when not to (enrichment), directing to string_enrichment as alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_helpSTRING: Help / FAQAInspect
Provides explanatory text for STRING features and limitations.
Use this tool when the user question involves:
What is STRING is or how to use the tool (how_to_use_string, cytoscape)
functionality not available via MCP tools (e.g. GSEA, regulatory networks, large datasets).
meaning of the lines in the network (line_colors)
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description implies a read-only, informational behavior by stating it provides explanatory text. It doesn't cover edge cases or limitations, but the nature of a help tool minimizes the need.
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 concise with a clear initial statement and bullet points for usage guidelines. No extraneous 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 presence of an output schema and the straightforward nature of a help tool, the description covers the purpose, usage, and parameter context adequately. It is complete for the tool's function.
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 0% coverage, but the description lists example topics in the usage guidelines (e.g., gsea, regulatory_networks). However, it does not explicitly describe the 'topic' parameter or its values, relying on the schema's enum.
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 it provides explanatory text for STRING features and limitations, listing specific topics. This distinguishes it from sibling tools which perform data retrieval or analysis.
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 explicitly lists when to use the tool with bullet points covering types of questions (what STRING is, unavailable functionality, line colors). This provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_homologySTRING: Get homologs in specified target speciesAInspect
Retrieves pairwise protein similarity scores (Smith–Waterman bit scores) for the query proteins.
If no target species (
species_b) is provided, results are intra-species (within the query species).To retrieve homologs in other species or clades (e.g. vertebrates, yeast, plants), specify one or more NCBI taxon IDs in
species_b.Multiple target species are supported; ask the user to clarify if needed.
Always report species names together with their taxon IDs.
Bit scores < 50 are not reported.
Results are truncated to the top 50 proteins per input protein.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein identifiers, separated by %0d. Example: SMO%0dTP53 | |
| species_b | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses bit score threshold (<50 not reported), truncation to top 50, and multiple species support. No contradictions.
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?
Well-structured with bullet points, front-loaded main purpose, each sentence adds value. No fluff.
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?
Covers purpose, scope, thresholds, truncation, and species reporting. Output schema likely provides return details. Missing minor behavioral details but adequate.
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 33% (low), but description adds context beyond schema: intra-species default, multiple species support, reporting requirement. Does not detail each parameter extensively.
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?
Clearly states it retrieves pairwise protein similarity scores (Smith-Waterman bit scores). Distinguishes from sibling tools like interactions or enrichment.
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?
Provides explicit guidance on intra-species vs. cross-species use, multiple target species, and asks to clarify client needs. Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_interaction_evidenceSTRING: Get links to interaction evidence pagesAInspect
Retrieves direct links to STRING evidence pages for protein–protein interaction pairs.
Use this tool only when a STRING evidence page/link is needed. To determine whether
an interaction is supported, use string_interactions_query_set.
It returns URLs linking to STRING’s evidence pages, which display the underlying data sources
(experimental results, publications, and curated databases) supporting each predicted interaction.
A URL can be generated even for unsupported pairs; the URL is not itself an interaction verdict.
Parameters:
identifier_a: Query protein identifier (Protein A)
identifiers_b: One or more target protein identifiers (Protein B), separated by
%0dspecies: NCBI taxonomy ID (e.g.
9606for human or10090for mouse)
Typical user questions that should trigger this tool:
"Can you show me the STRING evidence for this interaction?"
"Show me the details supporting this interaction."
"What supports the interaction between TP53 and MDM2?"
"Where can I find the STRING evidence for this pair?"
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| identifier_a | Yes | Required. Protein A identifier. | |
| identifiers_b | Yes | Required. One or more protein B identifiers, separated by %0d. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that a URL can be generated even for unsupported pairs and that the URL is not an interaction verdict. It also states what the returned URLs link to, providing full behavioral 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 well-structured: it begins with a clear purpose, then usage guidance, behavioral details, parameter explanations, and example trigger questions. Every sentence adds value without redundancy.
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 the tool and the presence of an output schema, the description covers purpose, usage, parameters, and behavior comprehensively. It leaves no gaps for an agent to misunderstand.
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 already describes all three parameters, but the description adds examples for species (e.g., '9606 for human or 10090 for mouse') and explains that `identifiers_b` are separated by '%0d', which adds clarity beyond the schema.
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 it retrieves direct links to STRING evidence pages for protein-protein interaction pairs. It uses a specific verb ('retrieves') and resource ('links to STRING evidence pages'), distinguishing it from sibling tool `string_interactions_query_set`.
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 explicitly says 'Use this tool only when a STRING evidence page/link is needed' and directs to `string_interactions_query_set` for checking interaction support. It also lists typical user questions that should trigger this tool, providing clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_interactions_query_setSTRING: Get interactions within query setAInspect
Retrieves the interactions between the query proteins. Use this method only when you specifically need to list the interactions between all proteins in your query set. If user asks for 'physical' or 'complex' use 'physical' network type.
For a single protein, the network includes that protein and its top 10 most likely interaction partners, plus all interactions among those partners.
For multiple proteins, the network includes all direct interactions between them.
If the user refers to "physical interactions", "complexes", or "binding", set the network type to "physical".
STRING does not store or report information about self-interactions/homomers; if asked, explain the limitation.
If few or no interactions are returned, consider reducing the required_score.
For large query sets (>50 proteins), consider increasing the required_score (e.g. ≥700)
to focus on high-confidence interactions and avoid overly dense networks.
Expand the names of score sources:
nscore(neighborhood),fscore(fusion),pscore(phylogenetic profile),
ascore(coexpression),escore(experimental),dscore(database),tscore(text-mining)
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein identifiers, separated by carriage return (%0d). Example: SMO%0dTP53 | |
| network_type | No | ||
| extend_network | No | ||
| required_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: single protein includes top 10 partners, multiple proteins show direct interactions, STRING doesn't store self-interactions, and score adjustments. Does not explicitly state it's a read-only operation, but inference is clear. Could mention output format but output schema exists.
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?
Description is appropriately sized and front-loaded with purpose. Every sentence adds useful guidance, though some repetition (e.g., single vs multiple proteins). Could be slightly more concise but still effective and well-structured.
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, many siblings), the description covers all necessary aspects: behavior, usage guidelines, parameter adjustments, and limitations. Output schema exists, so no need for return value explanations. Complete for an agent to select and invoke correctly.
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 coverage is 20% (only some parameters described in description), but schema already has descriptions for all parameters. Description adds value by explaining when to set 'network_type' to 'physical', when to adjust 'required_score', and expands score source names (e.g., nscore, fscore) which are not in schema. Does not add extra for proteins or species, but sufficient.
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 it retrieves interactions between query proteins, using specific verb 'retrieves' and resource 'interactions'. It distinguishes from siblings by emphasizing 'query set' and listing all interactions, which is specific to this tool compared to other interaction tools like 'string_all_interaction_partners'.
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 explicitly states when to use: 'Use this method only when you specifically need to list the interactions between all proteins in your query set.' It also gives alternatives for physical/complex interactions, adjustments for single vs multiple proteins, and score thresholds for large query sets. Provides clear context excluding other approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_network_clusteringSTRING: Perform network clusteringAInspect
Performs network clustering on a STRING interaction network and returns both a network image URL and details about each detected cluster.
Use the same parameters as in the network creation step to ensure consistency. If the network already contains disconnected subgraphs, the resulting number of clusters may differ from the requested value.
Dashed lines represent connections between clusters, while solid lines indicate interactions within clusters.
Notes:
For small queries (≤5 proteins), the
required_scoreparameter is automatically lowered to 0.If only a single cluster is produced, try increasing
required_score, adjusting the inflation parameter, or switching tokmeansfor small, highly interconnected networks.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein identifiers (optionally with values). Example: PTEN 0.234 SMO -3.445 Separate entries with newline (%0d). Numeric values (e.g. expression data) can be provided after identifiers. | |
| network_type | No | ||
| extend_network | No | ||
| network_flavor | No | ||
| required_score | No | ||
| center_node_labels | No | ||
| clustering_algorithm | No | ||
| clustering_parameter | No | ||
| hide_disconnected_nodes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 discloses automatic lowering of required_score for small queries, behavior with disconnected subgraphs, and visual conventions (dashed/solid lines). It does not mention potential destructive effects or authentication, but the tool appears to be read-only. This is reasonably transparent.
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 concise with a clear front-loaded purpose, followed by usage guidance and bulleted notes. Each sentence provides useful information without redundancy. The structure is well-organized.
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 (10 parameters, output schema exists), the description covers key aspects: purpose, usage context, behavioral nuances, and troubleshooting. The existence of an output schema means return values need not be detailed. It is sufficiently complete for an agent to understand when and how to use the tool.
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 descriptions for all parameters, so the baseline is 3. The description adds value by noting the automatic lowering of required_score for small queries and suggesting parameter adjustments for clustering. However, it does not elaborate on other parameters beyond the schema, and the context indicates 10% schema coverage, but the actual schema seems well-documented.
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 it performs network clustering on a STRING interaction network and returns a network image URL and cluster details. The verb 'Performs network clustering' and resource 'STRING interaction network' are specific, and the tool is distinct from sibling tools like string_visual_network or string_network_link which do not focus on clustering.
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 advises using the same parameters as in network creation to ensure consistency, implying it should be used after a network is created. It also provides troubleshooting hints for single-cluster output. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_network_linkSTRING: Get interactive network link (web UI)AInspect
Retrieves a stable URL to an interactive STRING network for one or more proteins.
For a single protein: includes the protein and its top 10 most likely interactors.
For multiple proteins: includes all known interactions within the query set.
If the user asks for "physical interactions", "complexes", or "binding", set
network_typeto "physical".
The input may include one numeric value per protein, such as fold change, effect size, or score. These values are visualized as colored halos around the nodes, allowing overlay of protein-level measurements on the network.
Example: PTEN 2.1 SMO -1.3
If numeric values are provided:
positive values are shown in blue
negative values are shown in red
larger absolute values produce stronger halo intensity
If the user provides numeric values together with the proteins, preserve them in the query.
If few or no interactions are shown, consider lowering required_score.
For large queries (>100 proteins):
use
network_flavor="confidence"increase
required_score(e.g. 700)
Always display the link as a markdown hyperlink (hide the raw URL).
Input parameters should match those used in related STRING tools unless otherwise specified.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein IDs, optionally followed by one numeric value per protein. Example: PTEN 0.234 SMO -3.445 Use newline (%0d) between entries. Tabs and spaces are accepted as separators. | |
| network_type | No | ||
| extend_network | No | ||
| network_flavor | No | ||
| required_score | No | ||
| hide_disconnected_nodes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool returns a stable URL, explains behavior for single vs. multiple proteins, numeric value visualization, and large query handling. It does not mention any side effects or destructive actions, but for a read-only tool this is sufficient.
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 well-structured with bullet points and examples, but it is somewhat verbose and repeats numeric value handling in both prose and an example. Some redundancy reduces conciseness.
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 (7 parameters, multiple scenarios), the description covers essential aspects: single vs. multiple proteins, numeric value overlay, large query advice, and output format. It provides enough context for an AI agent to use the tool correctly.
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 low (14%), but the description adds meaning for key parameters: network_type, required_score, network_flavor, hide_disconnected_nodes, and the proteins format including numeric values. This compensates well for the schema gaps.
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 that the tool retrieves a stable URL to an interactive STRING network for one or more proteins, and distinguishes behavior for single vs. multiple proteins. It is specific and informative.
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 explicit guidance on when to set network_type, how to handle numeric values, lowering required_score if few interactions, and adjusting parameters for large queries. While it does not explicitly contrast with sibling tools, the instructions are comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_ppi_enrichmentSTRING: Protein–protein interaction (PPI) enrichmentBInspect
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"
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| identifiers | Yes | Required. One or more protein identifiers, separated by %0d. Example: SMO%0dTP53 | |
| required_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the statistical assessment and output, but does not mention side effects, permissions, or read-only nature. The description implies non-destructive behavior but is not explicit.
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 moderately concise but includes redundant phrasing (e.g., p-value explanation twice). It front-loads purpose but the output fields list could be more concise, and the note about related tools seems tangential.
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 and presence of an output schema, the description covers output fields adequately but lacks details on input parameters and the statistical method. It provides a high-level overview but is not fully complete for a complex statistical tool.
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?
With only 33% schema description coverage, the description should compensate but fails to add meaning beyond the schema. It only provides an example for identifiers and does not elaborate on species or required_score, leaving gaps for users.
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 tests for network enrichment in protein-protein interactions, with specific verb and resource. It distinguishes itself among siblings through its focus on enrichment, but does not explicitly differentiate from sibling tools like string_enrichment.
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 explains what the tool does and provides an example, but lacks explicit guidance on when to use versus alternatives or when not to use. The note about using same input parameters for related tools provides some context but is not specific to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_proteins_for_termSTRING: Retrieve proteins associated with a functional termAInspect
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_termis setstringIds: STRING protein identifiers when returned
preferredNames_omitted: True when a row omits the protein-name list
stringIds_omitted: True when STRING identifiers are omitted
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | NCBI/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_text | Yes | Required. Functional term identifier (GO, KEGG, Reactome, etc.) or descriptive free text (e.g. 'hsa05218', 'Melanoma', 'GO:0008543', 'Fibroblast growth factor'). | |
| detail_for_term | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Retrieve proteins' implying read-only, and cautions that 'results reflect annotation depth within each category; use caution when interpreting.' It also notes the single-species limitation. Does not explicitly confirm no side effects, but the read-only nature is clear.
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 somewhat verbose, with a separate list of output fields that are partly redundant with the output schema. The key information is front-loaded, but the output field list could be more concise. Still, it is well-organized and readable.
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 output schema exists, the description still covers return values and provides edge-case handling (simplify query, tissue nomenclature). It addresses limitations (single species) and usage context. For a retrieval tool, this is quite complete.
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 coverage is 67%; the description adds value by providing examples for term_text (e.g., 'hsa05218', 'Melanoma'), clarifying the single-species constraint for species, and explaining the purpose of detail_for_term. This goes beyond the schema's basic descriptions.
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 it retrieves proteins annotated with a functional term or descriptive text in a single species. It lists specific query types (tissues, compartments, diseases, etc.) and the resource (STRING). The purpose is distinct from sibling tools like string_enrichment (which does enrichment analysis) or string_functional_annotation (which annotates proteins).
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?
Provides explicit guidance: for cross-species queries, run separately per species; simplifies query if no results; recommends BRENDA tissue nomenclature. However, it does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_query_speciesSTRING: Query species and clades in STRINGAInspect
Search for species or clades available in STRING by free-text query and return their NCBI taxonomy IDs.
Use this when the user asks which species or clades are present in STRING, or when you need the correct NCBI taxon ID to pass to other tools.
use this to resolve NCBI taxons IDs to their scientific names.
Accepts up to 100 taxon IDs separated by
%0d.The results are limited to the top 50 matches per query.
When the user asks for a species list, do not list clades.
If the requested species cannot be matched (i.e. the correct species is not present in the results), immediately invoke the 'string_help' tool with topic='missing_species'.
| Name | Required | Description | Default |
|---|---|---|---|
| species_text | Yes | Required. One species/clade search term or multiple NCBI taxon IDs separated by carriage return (%0d). Examples: 'human', 'mouse', 'vertebrates', '511145', or '9598%0d10090'. For multiple queries, use taxon IDs rather than free-text names. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavioral traits: accepts up to 100 taxon IDs separated by '%0d', results limited to top 50 matches per query, and the immediate help invocation for unmatched species. No contradictions.
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?
Description is concise and well-structured with bullet points. Every sentence serves a purpose, and the key points are front-loaded: free-text query, use case, and specific behaviors.
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?
Has output schema (not shown but referenced). The description covers core functionality, usage, limits, and error handling. However, there is slight ambiguity about whether it returns only NCBI taxonomy IDs or also scientific names, as it mentions resolving taxon IDs to scientific names. Still, it is largely complete for a simple query tool.
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 coverage is 100% for the single parameter species_text. The description adds significant value beyond the schema by providing concrete examples, format details (%0d for multiple IDs), and a constraint (up to 100 taxon IDs). This enhances agent understanding.
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 explicitly states it searches for species or clades by free-text query and returns NCBI taxonomy IDs. It clearly distinguishes this species/clade lookup tool from sibling tools like string_resolve_proteins or string_homology.
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?
Provides explicit when-to-use (user asks which species/clades present or needs NCBI taxon IDs) and when-not-to-use (do not list clades when user asks for species list). Additionally, it specifies the fallback action of invoking string_help with topic='missing_species' when the requested species cannot be matched.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_resolve_proteinsSTRING: Resolves protein identifiers to metadataAInspect
Maps one or more protein identifiers to their corresponding STRING metadata, including: gene symbol, description, sequence, domains, species, and internal STRING ID.
This method is useful for translating raw identifiers into readable, annotated protein entries.
Example input: "TP53%0dSMO"
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more input protein identifiers (gene symbols, UniProt IDs, etc.), separated by carriage return (%0d). Example: TP53%0dSMO | |
| show_sequence | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention any behavioral traits such as rate limits, authentication, idempotency, or error handling. The description implies a read operation but lacks confirmation or further context.
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 very concise with three sentences plus an example, all relevant and front-loaded. Every sentence contributes meaningful information with no redundancy or filler.
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 low complexity and the presence of an output schema, the description adequately covers the tool's functionality. It lists key output fields and provides an example, but lacks details on edge cases or error behavior. Overall, it is sufficiently complete for a simple lookup tool.
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 already provides descriptions for all three parameters (100% coverage based on provided JSON, though context says 33%). The description adds value by listing output fields and providing an example with separator format, but this is not essential for parameter understanding. Baseline 3 is appropriate given schema richness.
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 ('maps') and resource ('protein identifiers to metadata'), and lists specific metadata fields returned. It effectively distinguishes from siblings like string_proteins_for_term and string_homology, which 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 a usage hint ('translating raw identifiers into readable, annotated protein entries') and an example input, but lacks explicit guidance on when to prefer this tool over alternatives or when not to use it. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_sequence_searchSTRING: Search proteins by amino acid sequenceAInspect
Searches the STRING database using amino acid sequences to identify matching proteins.
Accepts a single sequence or multiple sequences in FASTA format.
Returns the most similar STRING protein(s) for the specified species, based on sequence similarity.
Use this when the protein identifier is unknown or unresolvable by
string_resolve_proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | Required. NCBI or STRING taxonomy ID. You can query with a clade or species. eg.g 2 for bacteria, 7742 for vertebrates, 511145 for E. coli | |
| sequences | Yes | One or more protein sequences in plain or FASTA format.For multiple sequences, use standard FASTA headers (lines beginning with '>'). Only amino acid sequences are supported — nucleotide sequences are not accepted. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: accepts single/multiple FASTA sequences, returns similar STRING proteins for a specified species. No contradictions.
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?
Short, bulleted, front-loaded. Every sentence adds critical information with no redundancy.
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 presence of an output schema, the description covers all necessary context: input format, required species, and return type. Appropriate for a search tool.
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 coverage is 100%, but the description adds value by clarifying that species can be a clade or species and that sequences must be amino acids, not nucleotides.
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?
Clearly states the verb (searches), resource (STRING database), and method (amino acid sequences). Distinguishes from sibling tools like string_resolve_proteins.
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?
Explicitly tells when to use this tool ('when the protein identifier is unknown or unresolvable by string_resolve_proteins'), providing clear guidance and referencing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_visual_networkSTRING: Get interaction network image (image URL)AInspect
Retrieves a URL to a STRING interaction network image for one or more proteins.
For a single protein: includes the protein and its top 10 most likely interactors.
For multiple proteins: includes all known interactions within the query set.
If the user asks for "physical interactions", "complexes", or "binding", set
network_typeto "physical".
The input may include one numeric value per protein, such as fold change, effect size, or score. These values are visualized as colored halos around the nodes, allowing overlay of protein-level measurements on the network.
Example: PTEN 2.1 SMO -1.3
If numeric values are provided:
positive values are shown in blue
negative values are shown in red
larger absolute values produce stronger halo intensity
If the user provides numeric values together with the proteins, preserve them in the query.
If few or no interactions are shown, consider lowering required_score.
For large queries (>100 proteins):
use
network_flavor="confidence"increase
required_score(e.g. 700)
Always ask if the user also wants a link to the interactive STRING network page.
Input parameters should match those used in related STRING tools (e.g. string_interactions_query_set), unless otherwise specified.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein IDs, optionally followed by one numeric value per protein. Example: PTEN 0.234 SMO -3.445 Use newline (%0d) between entries. Tabs and spaces are accepted as separators. | |
| network_type | No | ||
| extend_network | No | ||
| network_flavor | No | ||
| required_score | No | ||
| center_node_labels | No | ||
| do_not_show_structures | No | ||
| hide_disconnected_nodes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a URL (read operation), explains how numeric values are visualized (blue/red halos), and describes the network expansion for single vs. multiple proteins. No side effects or auth requirements are mentioned, but the output is clearly a static image.
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 well-structured: main purpose first, then bullet points, an example, and usage tips. It is not overly verbose, but a few sentences (e.g., the part about always asking for interactive link) could be slightly more concise. Overall, it earns its length.
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 9 parameters (many optional) and the existence of an output schema, the description is reasonably complete. It covers key behaviors, input format, parameter selection guidance, and the output nature (URL). It could mention that the URL is for an image only, but that is implied.
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 descriptions are already detailed for each parameter (high coverage), so the baseline is 3. The description adds significant value by explaining the single vs. multiple protein network behavior, the visualization of numeric values as halos, and providing an example input. This goes beyond the schema's per-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 clearly states the tool 'Retrieves a URL to a STRING interaction network image' (specific verb and resource). It also distinguishes behavior for single vs. multiple proteins and hints at differentiation from sibling tools like string_network_link by focusing on image output.
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?
Provides context on when to use parameters (e.g., network_type for physical interactions, required_score for thresholds, network_flavor for large queries) and includes tips like lowering required_score for few interactions. However, it does not explicitly name alternative tools for when the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!