Query STRING interactions, enrichment, annotations, homology, and PPI networks.
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.
Average 4.3/5 across 17 of 17 tools scored. Lowest: 2.9/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.
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.
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.
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.
string_all_interaction_partnersSTRING: Get all interaction partners for proteinsAInspectRetrieves 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 network tool, 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It clearly states that the tool returns all known interactions with any other protein in the database, not just within the query set, which is a key behavioral trait. It also explains that network_type can be set to physical for binding/complex questions and lists evidence score types. However, it does not mention output format, potential large result sets, or any rate limits. Given the output schema exists, the lack of output details is acceptable, but the description could be more transparent about result size or pagination.
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-organized and front-loaded with the core purpose. It uses clear, purposeful bullets for evidence scores and keeps sentences short and actionable. Every sentence contributes to understanding the tool, with no redundant fluff. The length is appropriate for the complexity and the lack of annotations.
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?
The description covers the tool's purpose, usage, differentiation from a key sibling, parameter guidance, and evidence scores. Since an output schema exists, the description does not need to explain return values. Minor gaps include no discussion of species handling or handling of very large result sets, but the description is largely complete for a query tool of this type.
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 only 25%, so the description must compensate. It adds meaningful semantics for network_type ('Set physical only for binding, complex, or co-complex questions') and required_score ('You can filter for strong interactions using required_score'), as well as listing evidence score types (nscore, fscore, etc.). It does not explicitly explain species, but the schema does include a description for species. Compared to a baseline of 1 for low coverage, the description adds substantial value for two of the four parameters.
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 starts with a specific verb and resource: 'Retrieves all interaction partners for one or more proteins from STRING.' It clearly states the scope ('all known interactions between your query protein(s) and any other proteins') and explicitly distinguishes itself from the network tool, which only shows interactions within the input set. This fully clarifies what the tool does and how it differs from a sibling.
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 usage guidance: 'Use this when asking "What does TP53 interact with?"' and contrasts it with the network tool, noting the network tool only shows interactions within the input set or a limited extension. It also gives conditional advice: 'If the user refers to "physical interactions", "complexes", or "binding", set the network type to "physical".' This tells the agent when to use this tool and how to adjust behavior for specific user intents.
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 fileAInspectCreates 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does disclose key behaviors: do not create the file until asked, and do not store unrelated data. However, it doesn't mention potential side effects (e.g., file storage duration, access controls, overwrite behavior) or what the tool returns. The output schema may cover return values, but the description alone leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening sentence, followed by usage conditions, proactive guidance, and prohibitions. Every sentence adds value, and the structure front-loads the primary purpose before moving to procedural details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is quite complete. It covers when to use, what to include, and what to avoid. It could mention error handling or the post-creation outcome (e.g., URL or file path), but the output schema likely covers returns. The guidance is sufficient for an agent to decide when and how to invoke this 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 100%, so the parameters (filename and content) are fully documented in the schema. The description reinforces that content must be STRING-derived and mentions file types (.tsv, .csv, etc.), but adds little beyond the schema's detailed parameter descriptions. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates a downloadable file') and clearly specifies the resource (STRING-derived results). It distinguishes itself from sibling tools by focusing on file creation/export rather than analysis, and even lists the types of data that can be exported (tables, protein lists, enrichment results, networks).
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 this tool: 'when the user explicitly asks to download, save, export, or receive a file containing STRING data'. It also provides guidance on proactively mentioning downloadable files for publication-style tables and instructs not to create the file until the user asks. It doesn't explicitly name alternative sibling tools for when not to use it, but the context is clear.
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 analysisAInspectThis 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.
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | ||
| proteins | Yes | Required. One or more protein identifiers, separated by %0d. Example: SMO%0dTP53 | |
| expand_category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
string_enrichment_image_urlSTRING: Get enrichment result figure (image URL)CInspectRetrieves 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states that the tool retrieves a URL, implying a read-only operation, but discloses no additional behavior such as whether the URL is temporary, rate limits, or failure modes. It adds no context beyond the basic action.
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, focused sentence with no filler. It front-loads the key action and object, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple URL retrieval tool, the description is adequate for basic purpose, but given 7 parameters and an output schema, it lacks guidance on parameter usage and selection among sibling tools. The output schema covers return values, but the description doesn't explain any prerequisites or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 14% at the property level, and the tool description does not compensate. It only mentions 'a set of proteins' without explaining how identifiers should be formatted, what species is required, or how optional parameters affect the output. The nested schema descriptions exist but are not surfaced, so the description adds minimal parameter insight.
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 uses 'Retrieves' as a specific verb and names the resource 'STRING enrichment figure image URL' for a set of proteins. It clearly states what the tool does, but it does not explicitly differentiate from sibling tools like string_enrichment or string_ppi_enrichment, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives. It doesn't mention that this is for obtaining the visualization URL rather than enrichment data, nor does it give context like 'use when you need the figure.' There is no exclusion or alternative mention.
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 proteinsAInspectThis 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explains that output is curated and intentionally short ('Keep the output short and focused'), mentions the types of data sources (GO, KEGG, UniProt Keywords), and discloses a limitation (no enrichment). It does not mention potential truncation details, but the schema parameter detail_for_term fills in that gap.
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 a clear opening sentence, bullet points for usage, and an output field list. It is somewhat long but every section adds useful information; the front-loaded purpose statement makes it easy to scan.
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?
The description covers the tool's purpose, appropriate use cases, a key alternative, and detailed output fields. With an output schema present, it does not need to restate return types. It could mention the requirement for species, but the schema covers that, so overall completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not explain any of the three parameters by name or provide usage details. Schema description coverage is only 33%, and the description does not compensate by clarifying how to format identifiers, supply species, or use detail_for_term. The output field list is helpful but does not address parameter semantics.
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 opens with a specific verb and resource: 'retrieves curated functional annotations for a set of proteins.' It clearly distinguishes itself from sibling tools by explicitly stating it does not perform statistical enrichment and points to the enrichment tool for that purpose.
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 gives explicit when-to-use guidance: 'Use this when the user asks what a protein does, where it's localized, expressed, or which pathways it participates in.' It also provides an exclusion and alternative: 'This tool does not perform statistical enrichment — use the enrichment tool for that.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
string_helpSTRING: Help / FAQAInspectProvides 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool returns explanatory text and gives context on the type of content covered. It doesn't mention side effects (none expected for a help tool) or details about behavior when the topic is omitted, but the schema covers that, so the description adds reasonable 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 concise and front-loaded with the purpose, followed by a tight bulleted list of usage scenarios. Every sentence earns its place, and the structure makes it easy to scan. Minor typo ('What is STRING is') does not detract from clarity.
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 is a simple help/FAQ tool with an output schema and a single optional parameter, the description provides sufficient context: what it does, when to use it, and examples of relevant topics. It is complete for its complexity.
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 describes the 'topic' parameter as optional and notes the behavior when omitted. The tool description adds semantic value by grouping example topics (how_to_use_string, cytoscape, line_colors) into meaningful categories, helping the agent map user questions to appropriate parameter values.
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 provides explanatory text for STRING features and limitations, which is a specific verb+resource. It distinguishes from sibling tools by positioning itself as a help/FAQ tool rather than a data retrieval tool, and reinforces this with example topics.
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 'Use this tool when the user question involves:' and lists three distinct scenarios, including guidance for functionality not available via MCP tools. This clearly differentiates when to use this tool versus alternatives.
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 speciesAInspectRetrieves 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two important behavioral constraints: bit scores below 50 are not reported and results are truncated to the top 50 per protein. It also mandates reporting species names with taxon IDs, which sets expectations for output. However, it does not explicitly state the operation is read-only or mention any API/authentication requirements.
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 front-loaded with the main purpose and then uses bullet points for scannable behavioral details. Every line adds value—no filler, rhetorical fluff, or redundant restatements of the title. It's tight but complete.
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?
The description covers the essential usage contexts (intra-species vs cross-species), output filters (bit score threshold, top-50 truncation), and reporting expectations. The presence of an output schema helps with return-value details. The main gap is the missing explanation of the 'species' parameter, which prevents full self-sufficiency.
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 clarifies the role of species_b (optional, intra-species when omitted) but does not explain the 'species' parameter or the encoding format for 'proteins'. Given the low schema description coverage (33%), the description should compensate by explaining parameter meanings, but it leaves one parameter unaddressed and repeats only what the schema already says for another.
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 opens with a specific verb and resource: 'Retrieves pairwise protein similarity scores (Smith–Waterman bit scores) for the query proteins.' It clearly differentiates from sibling tools by focusing on homology across specified target species, matching the title's promise.
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?
It clearly states when to use the tool (to retrieve homologs) and the key branching condition: no species_b means intra-species, while specifying taxon IDs enables cross-species/clade searches. It also advises asking the user to clarify multiple target species, but doesn't name alternative tools or explicitly exclude their use.
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 pagesAInspectRetrieves 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 %0d
species: NCBI taxonomy ID (e.g. 9606 for human or 10090 for 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 a key nuance: 'A URL can be generated even for unsupported pairs; the URL is not itself an interaction verdict.' It also explains what the evidence pages display, which adds meaningful context beyond the basic retrieval purpose.
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 and front-loaded with the purpose. The parameter list and typical user questions add value but make it slightly longer than necessary. The caveat about unsupported pairs is placed prominently, and the overall organization makes it easy to scan.
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?
The description covers the tool's purpose, usage, and output nature, and the presence of an output schema covers return details. The only notable gap is that it doesn't mention the `species` parameter is optional with a null default, which could lead to confusion given the schema marks it as 'Required' in its description. Otherwise, it is 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 description adds clarity to the two required parameters by restating them in plain language and adding the separator detail for `identifiers_b` ('separated by `%0d`'). It also provides concrete species examples (9606, 10090) that go beyond the schema's description. Since schema coverage is 67%, this added context helps compensate.
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 opens with a specific verb and resource: 'Retrieves direct links to STRING evidence pages for protein–protein interaction pairs.' It clearly distinguishes itself from the sibling tool by noting that `string_interactions_query_set` should be used to determine if an interaction is supported, making the purpose unambiguous.
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 this tool with 'Use this tool only when a STRING evidence page/link is needed' and provides the alternative: 'To determine whether an interaction is supported, use `string_interactions_query_set`.' It also lists typical user questions that should trigger the tool, giving clear contextual guidance.
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 setAInspectRetrieves 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds. It discloses behavior for single vs multiple proteins, the default 10 partners, the physical network type mapping, the lack of self-interactions/homomers and how to handle such queries, and the effect of required_score adjustments.
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 a clear opening purpose, followed by actionable use cases, behavior notes, tuning advice, and a final score-source legend. Each sentence earns its place; the use of bullets and bold improves readability without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 5 parameters and no annotations, the description covers the essential behavioral aspects, limitations, parameter tuning, and even auxiliary knowledge (score source names). Combined with the input schema (which documents parameter formats) and the presence of an output schema, this is complete enough for effective tool usage.
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 valuable meaning beyond the schema, especially for network_type ('set physical only for binding, complex, or co-complex questions'), required_score (when to reduce or increase threshold), and the expansion of score source abbreviations. However, it does not explicitly explain the proteins format or species, which the schema partially does; given low schema coverage, this is a minor gap.
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 'Retrieves the interactions between the query proteins' with a specific verb and resource, and further distinguishes its scope with 'Use this method only when you specifically need to list the interactions between all proteins in your query set.' This differentiates it from sibling 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?
It gives explicit guidance on when to use: 'only when you specifically need to list the interactions between all proteins in your query set.' It also covers network type selection, single vs multiple protein behavior, and parameter tuning (reducing required_score for sparse results, increasing for large sets). These are clear contextual instructions for the agent.
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 clusteringAInspectPerforms 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_score parameter is automatically lowered to 0.
If only a single cluster is produced, try increasing required_score, adjusting the inflation parameter,
or switching to kmeans for 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations given, the description fully carries the burden of behavioral disclosure. It reveals important non-obvious behaviors: automatic lowering of required_score for ≤5 proteins, possible mismatch in cluster count for disconnected subgraphs, the meaning of dashed vs solid lines, and adjustment tips for single-cluster results. This exceeds typical descriptions.
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: a concise opening sentence, a usage note, a visual-guide sentence, and a bulleted list of caveats. Every sentence contributes new information without verbosity, and the most important purpose is front-loaded.
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, 1 required), the description provides sufficient context for correct invocation. It covers the tool's core function, consistency with network creation, edge-case behavior, and troubleshooting adjustments. The presence of an output schema mitigates the need to describe return values in the text.
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 provides thorough descriptions for all 10 parameters, including defaults and examples. The description adds contextual meaning beyond the schema by explaining the relationship between required_score and small queries, and by elaborating on clustering_parameter behavior (inflation vs number of clusters) in the troubleshooting note.
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 opens with 'Performs network clustering on a STRING interaction network' and specifies the two outputs: a network image URL and details about each detected cluster. This clearly identifies the tool's purpose and differentiates it from siblings like string_visual_network by focusing on clustering results.
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?
It advises 'Use the same parameters as in the network creation step to ensure consistency,' which implies a workflow context. It also provides concrete troubleshooting guidance (adjusting required_score, inflation parameter, or switching to kmeans) but does not explicitly name alternative tools 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_network_linkSTRING: Get interactive network link (web UI)AInspectRetrieves 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_type to "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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: the network content for single vs multiple proteins, how numeric values are visualized as halos with color coding, the markdown link instruction, and the suggestion to lower required_score when few interactions appear. This provides a clear behavioral model for the agent.
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 an example, making it easy to parse. It is longer than strictly necessary but every section serves a purpose: usage scenarios, numeric value semantics, and best practices. The only minor redundancy is repeating the numeric value color logic in two places.
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?
The description covers the main usage contexts, edge cases (large queries, few interactions), and output presentation (markdown hyperlink). With an output schema present, return values are already specified. The only missing piece is explicit handling of invalid protein IDs or error cases, but these are likely covered by the output schema or standard error handling.
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 meaningful context beyond the schema, especially for the proteins parameter with a concrete example and separator notes, and for network_type with the 'physical interactions' trigger. However, species, extend_network, and hide_disconnected_nodes are only covered by the schema's own descriptions, which are already self-explanatory. The description's note on matching parameters to related STRING tools is a useful cross-tool convention.
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 stable URL to an interactive STRING network for one or more proteins.' The verb 'retrieves' and the specific resource 'interactive STRING network URL' make the purpose explicit. It also distinguishes from siblings like string_visual_network by specifying 'web UI' link generation.
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 detailed when-to-use guidance for different query types (single protein vs multiple proteins), when to set network_type, required_score adjustments, and large query handling. However, it does not explicitly name alternative sibling tools or state when not to use this tool, so it falls short of a 5.
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) enrichmentBInspectThis 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the statistical methodology (observed vs expected edges) and provides output field interpretations (e.g., 'p_value: smaller = more enriched'). However, it does not mention potential side effects (though likely none), prerequisites like species handling, or behavior under invalid input, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullets and an output field list, but it includes extraneous elements like 'Report the p-value as a human-readable value' and 'When calling related tools...' which are not core tool-defining content. It could be tightened without losing key 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?
An output schema exists, so listing return fields is redundant but adds interpretive value. The description does not address when to provide required_score or how species defaults behave, and it lacks guidance on input prerequisites. It is adequate for basic selection but not fully complete for invocation without schema inspection.
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 (33%), so the description must compensate. It provides an example identifier format ('SMO%0dTP53') but does not clarify the semantics of the optional species or required_score parameters beyond what the schema already says. The phrase 'use the same input parameters' adds little specific 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 starts with a specific verb ('tests if your network is enriched') and clearly identifies the resource (protein-protein interactions) and the comparison (background proteome-wide distribution). This distinguishes it from sibling tools like string_enrichment, which likely focus on functional term 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 implies usage when one wants to assess whether a protein set is more functionally connected than random, but it does not explicitly state when to choose this tool over alternatives such as string_enrichment or string_network_clustering. The only related-tool note ('When calling related tools use the same input parameters') is about parameter reuse, not tool selection.
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 termAInspectRetrieve 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
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
string_query_speciesSTRING: Query species and clades in STRINGAInspectSearch 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses important behaviors: accepts up to 100 taxon IDs separated by %0d, limits results to top 50 matches, and instructs immediate fallback to string_help when a species isn't found. This goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening sentence followed by a focused bullet list covering use cases, constraints, and fallback behavior. Every sentence provides actionable 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 and the tool's moderate complexity, the description covers all critical aspects: purpose, usage timing, formatting constraints, result limits, and error handling. It is complete and self-sufficient.
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 provides 100% coverage for the single parameter, including examples and guidance to use taxon IDs for multiple queries. The description adds usage context but does not significantly expand the parameter's meaning beyond what the schema documents.
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 the tool searches for species or clades in STRING and returns NCBI taxonomy IDs. It distinguishes itself from siblings by focusing on species/clade queries and taxonomy ID resolution, rather than protein interactions or annotations.
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 use cases: 'when the user asks which species or clades are present in STRING' and 'when you need the correct NCBI taxon ID to pass to other tools'. It also includes a clear exclusion ('do not list clades when species list requested') and a fallback instruction to invoke string_help for missing species.
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 metadataAInspectMaps 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately implies a read-only mapping operation and lists what data to expect, but it does not disclose error handling, edge cases (e.g., invalid identifiers), or any operational constraints. The output schema helps, but the description could be more explicit about behavior such as separator handling or the effect of the show_sequence flag.
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 compact and front-loaded: it states the core function in the first sentence, adds a brief use-case statement, and gives a concrete example. No redundant or vague wording is present.
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?
The description covers the purpose, a typical scenario, and an example input. Since an output schema exists, return values are already structured. However, it omits mention of the optional species and show_sequence parameters and does not discuss potential limitations, so it is not fully complete for a tool with three parameters.
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 (33% per context), and while the description adds value via the input example ('TP53%0dSMO') and the concept of multiple identifiers, it does not explain the 'species' or 'show_sequence' parameters. The schema itself provides some description for these, but the description does not compensate fully for the low coverage.
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 uses a specific verb ('Maps') and clearly identifies the resource (protein identifiers) and the target (STRING metadata). It enumerates the metadata fields (gene symbol, description, sequence, domains, species, internal STRING ID), which distinguishes it from sibling tools like string_sequence_search or string_functional_annotation.
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 clear use case ('useful for translating raw identifiers into readable, annotated protein entries'), which gives context on when to apply the tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
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 sequenceAInspectSearches 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that multiple sequences are accepted in FASTA format and that results are based on sequence similarity for a specified species. However, it does not mention potential limitations, error behaviors, or how similarity is determined. It is adequate but not rich.
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 compact and well-structured: a clear opening sentence followed by three concise bullet points. No filler or redundant information; 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?
Given that an output schema exists (covering return format) and the schema covers parameters well, the description is quite complete. It captures the main use case, input format, and key alternative. Minor gaps (e.g., behavior with no matches, species requirement emphasis) are acceptable because the schema and output schema fill in some details.
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 covers both parameters with descriptions (100% coverage). The tool description adds meaningful semantic details beyond the schema: it specifies that sequences can be FASTA, that multiple sequences require headers, and that only amino acid sequences are accepted. This enriches the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Searches the STRING database') with a specific input ('amino acid sequences') and a clear goal ('identify matching proteins'). It differentiates from siblings by focusing on sequence-based search rather than identifier resolution, and the title reinforces this.
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 'Use this when the protein identifier is unknown or unresolvable by string_resolve_proteins', providing a clear use case and naming an alternative tool. This gives the agent direct guidance on when to choose this tool over a sibling.
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)AInspectRetrieves 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_type to "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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: single protein includes top 10 interactors; multiple proteins restrict to within query set; numeric values produce colored halos (blue positive, red negative) with intensity scaling; and troubleshooting steps like lowering required_score. These details add meaningful transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points, an example, and actionable instructions. It is longer than average but each section earns its place, and the primary purpose is front-loaded. No redundancy or 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?
For a complex tool with 9 parameters and an output schema, the description covers the main scenarios: single vs. multiple proteins, numeric value handling, parameter tuning for empty or large results, and cross-tool consistency. It omits some details (e.g., species, extend_network), but those are described in the schema, and the output schema covers return values. Overall, it is complete enough 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?
The schema covers all parameters with descriptions, but the description enriches several: proteins (numeric values, halos), network_type (set to 'physical' for binding/complexes), network_flavor (confidence for large queries), and required_score (lower when few interactions). This adds practical meaning beyond the schema, though the description does not mention species or structural options, which are left to 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 states 'Retrieves a URL to a STRING interaction network image for one or more proteins,' clearly identifying the tool's action (retrieve URL) and resource (STRING interaction network image). It also distinguishes this from sibling tools like string_network_link (interactive page) and string_interactions_query_set (query set) by emphasizing the image output and network visualization.
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 concrete usage guidance: behavior for single vs. multiple proteins, when to set network_type='physical', when to adjust required_score, and how to handle large queries with network_flavor='confidence'. It also instructs the agent to always ask about the interactive STRING page, implying that this tool does not return that link. This is strong guidance, though it does not explicitly name alternative tools for the interactive page.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.