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

With no annotations, the description carries the full behavioral burden. It does disclose meaningful scope behavior — that results extend to any protein in STRING rather than the input set — which is genuinely useful. However, it says nothing about result-size limits, truncation, pagination, or cost of a broad query, all of which matter for a tool that can return unbounded partner lists.

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?

Front-loads the core statement and the sibling differentiation, then uses bullets for use cases and evidence abbreviations. Reasonably tight, though the evidence-score list is a slight digression from the tool's selection decision and could be trimmed or deferred.

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 return values needn't be explained, and the description covers scope, alternative tool, and threshold filtering. It stops short of noting practical limits (very large result sets, species inference for non-human identifiers), which would matter for a multi-partner retrieval 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%, so the schema baseline is 3, but the description adds semantics the schema lacks: what `required_score` is for (confidence threshold filtering) and the meaning of the evidence channel abbreviations (nscore, fscore, pscore, etc.). It adds no extra guidance for `species` or `identifiers` 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?

States a specific verb and resource ('Retrieves all interaction partners for one or more proteins from STRING') and explicitly contrasts itself with the sibling `string_interactions_query_set`, which only covers interactions within the input set. An agent can distinguish the two without opening either schema.

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?

Gives a concrete use case ('What does TP53 interact with?') and an explicit alternative plus the condition that selects it (in-set interactions → `string_interactions_query_set`). It also names the condition for tightening results via `required_score`.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: create-on-demand gating, a guardrail against storing unrelated data/transcripts, and content-shape expectations. It omits though what happens on overwrite, size limits, storage location, or error conditions for a write tool.

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?

Front-loaded with the core purpose, then proceeds to usage rules and guardrails with no filler; every sentence is functional. It is somewhat long, with the proactive-mention paragraph reading more as agent workflow policy than tool definition, but nothing is wasted.

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 return values need no explanation, and params are fully schema-documented. Usage and gating behavior are well covered; only secondary write-behavior details (overwrite, limits, failures) are absent, which is minor given the strengths.

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% and the two parameters (content, filename) have rich inline descriptions covering format, delimiter, extension matching, and naming. The description adds nothing about parameters, so the baseline of 3 applies.

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?

States a specific verb+resource ('Creates a downloadable file for STRING-derived results') and its role is unmistakable against the analysis-oriented siblings, none of which produce files. An agent can immediately tell this is the export/serialization tool rather than an analysis tool.

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 defines when to use it ('when the user explicitly asks to download, save, export, or receive a file'), supplies a proactive-trigger scenario for publication-style tables, and crucially states when NOT to act ('Do not create the file until the user asks for it'). This is near-complete invocation routing.

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

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the non-obvious single-protein auto-expansion behavior, response capping that preserves category diversity, and the `preferredNames_omitted` trap with the correct workaround. It omits rate limits, auth requirements, and cost characteristics, so it stops short of exhaustive.

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 behavioral bullets are well front-loaded, but the description then enumerates every output field and response-metadata key even though an output schema already exists, which is largely duplicated content. The bulk is longer than needed for the incremental value it adds.

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 an output schema already documents return values, the description supplies everything else an agent needs: input-set semantics, expansion side effects, truncation handling, term-detail routing, and the fallback tool for omitted gene lists. Nothing essential is missing for correct invocation.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains how the protein count changes what `proteins` means conceptually, and clarifies `expand_category` should take a value from metadata.category_summary and yields expanded term coverage with a larger gene-list cutoff.

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 names a specific verb and resource ('retrieves functional enrichment for a set of proteins using STRING') and scopes the input semantics precisely. It also positions the tool against siblings by naming `expand_category` and `string_functional_annotation` as follow-ups, so an agent can distinguish it from adjacent enrichment 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?

Explicit when-to-use rules are given: a single protein triggers auto-expansion to 10 interactors, whereas two or more use the exact input set. It also states when to call `expand_category` (truncated or deeper detail) and when to switch to `string_functional_annotation` (preferredNames_omitted rows), plus the instruction to reuse the same parameters across related calls.

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

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

No annotations are provided, so the description carries the burden; it does disclose the key non-obvious behavior that each figure shows a single enrichment category and that multiple calls are required for multiple categories, and that outputs are image URLs. It omits any note on cost/rate limits or whether the call is side-effect free, but 'Retrieves' implies a read.

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?

Front-loaded single-sentence purpose followed by two tight bullets; every sentence adds routing or behavioral value and nothing is redundant.

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 the description need not explain the returned figure details, and it covers the routing and repeat-call semantics an agent needs. Only a brief note on read-only/no side effects would make it fully self-contained for an 8-parameter 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 description coverage is 100%, so the schema already documents every parameter including defaults and the enum meanings for category, x_axis, graph_type, and color_palette. The description only reinforces the `category` parameter indirectly; baseline 3 is correct when 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?

States a specific verb (Retrieves) and resource (STRING enrichment figure / image URL) scoped to a set of proteins, and explicitly separates itself from the sibling `string_enrichment` which returns terms/FDR values. An agent can distinguish the two without opening either schema.

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?

Names the alternative tool and the condition selecting it ('For the enriched terms and FDR values, use `string_enrichment`'), explains that each call yields one category so repeat calls are needed, and instructs the agent to reuse the same proteins/species as already-displayed results so the figure matches.

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

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses the output style ('short and focused, highlighting a few diverse and specific annotations'), implying truncated result sets rather than exhaustive output. It stops short of quantifying the cap or describing the 'many' substitution behavior in the main body, which would be the last piece of 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?

Front-loaded with purpose, then bullets for usage and a clean field list; the alternative-routing sentence sits where it belongs. The per-protein output field enumeration is the one section that does not earn its space, since an output schema already exists and covers return values.

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 read-oriented annotation lookup with a full output schema and 100% schema coverage, the description covers purpose, usage, exclusions, and result character adequately. It is arguably redundant to restate output fields rather than spending that space on behavior such as result-set size limits.

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 schema already documents species, identifiers, and detail_for_term, including the recovery workflow for shortened lists. The description adds no per-parameter syntax or format detail beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ('retrieves curated functional annotations for a set of proteins') and enumerates the source ontologies (GO, KEGG, UniProt Keywords). It also explicitly distinguishes itself from the enrichment sibling, so an agent can route correctly without opening either schema.

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?

Gives an explicit when-to-use condition ('when the user asks what a protein does, where it's localized, expressed, or which pathways it participates in') and an explicit when-not with the named alternative ('does not perform statistical enrichment — use the enrichment tool for that'). Nothing is left to inference.

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

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 implies a safe, read-only help lookup and mentions limitations, but does not explicitly disclose side effects, permissions, or rate-limit behavior.

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 purpose is stated in the first sentence, followed by a compact, well-structured bullet list of usage conditions. The format is front-loaded and every item helps an agent select the right topic.

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 definition is complete enough for a one-parameter help tool with an output schema, and it covers the main question categories. It leaves a small gap by not explicitly stating the read-only/no-side-effect behavior absent 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?

Schema coverage is 100%, so the enum and optional topic parameter are already documented. The description adds useful meaning by mapping user-question types to specific help topics such as how_to_use_string, network_edge_legend, and enrichment_scores.

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?

States a specific verb and resource: provides explanatory text for STRING features and limitations. It clearly distinguishes this help/FAQ tool from the data-query and analysis siblings by scoping it to interpretation, usage, and unsupported functionality.

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 bullet list gives clear contexts for when to use the tool, including unavailable functionality and interpretation questions. It does not explicitly name sibling alternatives to use instead, but the conditions are specific enough for routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the Smith-Waterman scoring method, the <50 bit-score reporting cutoff, and truncation to the top 50 proteins per input. It omits rate limits, error behavior, and authentication needs, keeping it just below the top score.

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?

Front-loads the core purpose in the opening sentence, then presents usage, constraints, and output behavior as scannable bullets. No filler; every bullet carries actionable 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?

For a read-only retrieval tool with an output schema covering return values, the description supplies everything needed to invoke it correctly: parameter behavior, the reporting threshold, and truncation limits. Despite absent annotations, the missing safety profile is low-risk for an obvious read operation.

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% so the baseline is 3, but the description adds genuine semantic value: it explains that omitting species_b yields intra-species results and that species_b accepts clades and multiple comma-separated IDs, plus the reporting convention for species names and taxon IDs. This meaning goes beyond the raw schema text.

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?

States a specific verb and resource ('retrieves pairwise protein similarity scores / homologs') and clarifies scope (intra-species vs. cross-species). An agent can tell this apart from string_sequence_search or string_resolve_proteins based on the homology-scoring focus without opening the schema.

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?

Gives clear when-to-use conditions: omit species_b for intra-species results, supply one or more taxon IDs (or clades) for cross-species. Explicitly tells the agent to ask the user to clarify when multiple target species are ambiguous. It stops short of naming sibling alternatives like string_sequence_search to route away from.

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

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

No annotations exist, so the description carries the burden — and it does real work by warning that a URL can be generated even for unsupported pairs and is not itself an interaction verdict, plus describing what the linked page shows (experimental results, publications, curated databases). It does not cover auth needs, rate limits, or error behavior, so it is strong but not complete.

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?

Core routing rule and the unsupported-pair caveat are front-loaded in the first lines, then parameters, then triggers. The four example questions are somewhat redundant with the usage rule and add length, but they are skimmable and not misleading.

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 4-parameter link-generator with an output schema, the description supplies the alternative tool, the semantic caveat about non-verdict URLs, parameter formats, and trigger scenarios. Nothing an agent needs to call it correctly is missing.

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 already 100%, so the baseline is 3; the description adds usable context by giving concrete species examples (9606 human, 10090 mouse) and restating the %0d separator convention. It slightly under-describes network_type by naming only `physical` and `regulatory` and omitting the functional/omit behavior that 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?

States a precise verb+resource (retrieves links to STRING evidence pages for protein–protein interaction pairs) and explicitly distinguishes itself from the sibling `string_interactions_query_set`, which resolves support status. An agent can tell the two apart without opening either schema.

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?

Gives an explicit inclusion rule ('use this tool only when a STRING evidence page/link is needed') and names the alternative for support determination. The sample trigger questions reinforce the intended routing with concrete user phrasings.

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

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

With no annotations, the description carries the full burden and does substantial work: it explains how the returned network is constructed for single vs. multiple proteins, and discloses the important limitation that STRING does not store/report self-interactions or homomers. It does not mention permissions, rate limits, or response shape, but output schema exists to cover returns.

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 core purpose and usage constraints are front-loaded, but the trailing bullet expanding 'score sources' (nscore, fscore, etc.) has no clear connection to this tool's parameters and reads like leftover content from a sibling evidence tool, adding noise that an agent must triage.

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 return values need not be described, and the description covers the remaining essentials: network construction semantics, a domain limitation, and threshold-tuning heuristics. It is largely complete for an agent to call the tool correctly, with the only gap being the ambiguous score-source glossary.

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%, so the baseline is 3, but the description adds value beyond the schema by explaining required_score behaviour (lower it for sparse results, raise to ≥700 for dense >50-protein sets) and by clarifying network composition tied to the proteins parameter. The score-source glossary at the end, however, references names that are not parameters of this tool, which weakens the parameter guidance.

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 names a specific verb+resource ('Retrieves the interactions between the query proteins') and immediately scopes it with 'Use this method only when you specifically need to list the interactions between all proteins in your query set.' That scoping implicitly distinguishes it from string_all_interaction_partners (single-protein partner lookup), though it never names the sibling explicitly.

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 clear when-to-use framing ('only when you specifically need...') and offers actionable tuning guidance: reduce required_score when few/no interactions return, raise it (≥700) for large query sets (>50 proteins). It stops short of explicitly naming alternative tools to use instead for other scenarios.

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

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

With no annotations, the description carries the full burden and does well: it discloses that required_score is auto-lowered to 0 for ≤5 proteins, that cluster count may differ from the requested value when disconnected subgraphs exist, and that inter-cluster edges default to faded. It stops short of stating auth/permission or rate-limit behavior, so not a 5.

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 purpose is front-loaded, and the notes are cleanly separated into a bulleted block. The mid-description instruction about producing a cluster table is an unusual formatting directive that slightly muddies the description's role, but overall it is well-sized with little waste.

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 return values need not be re-explained, and the edge-case notes (small queries, single-cluster fallback, disconnected subgraphs) cover the main failure modes for an 11-parameter clustering tool. Only the absence of sequencing guidance relative to sibling tools keeps it from a 5.

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 schema already documents all 11 parameters including clustering_algorithm and clustering_parameter semantics. The description adds only the behavioral note that required_score is auto-lowered for small queries and points at inter_cluster_edge_visibility; baseline 3 is appropriate 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?

States a specific verb and resource ('Performs network clustering on a STRING interaction network') and enumerates the outputs (image URL, interactive URL, cluster details). It implicitly distinguishes itself from the network-creation sibling by referencing 'the network creation step,' but does not name that sibling, so differentiation is contextual rather than explicit.

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?

Guidance is present but indirect: it says to reuse the network-creation parameters and offers troubleshooting ('If only a single cluster is produced, try increasing required_score...'). It never states when to choose this tool over string_visual_network or string_network_link, so the agent must infer the sequencing.

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

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

With no annotations, the description carries the full behavioral burden and does a good job: it discloses the return type (stable URL), single vs. multiple protein behavior, numeric value visualization via colored halos, and recommendations for large queries. It does not, however, mention authentication, rate limits, or explicitly state that the operation is read-only.

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 front-loads the core purpose. It is appropriately sized for a 7-parameter tool, though some content (e.g., the final line about matching related STRING tools) is vague and borderline unnecessary.

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, the description need not explain return values, but it still clarifies the output (markdown hyperlink) and covers large-query handling. It is largely complete, though it omits guidance on several parameters (species, extend_network, hide_disconnected_nodes) that are left entirely to the schema.

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%, so the baseline is 3. The description adds meaningful semantics beyond the schema: numeric values per protein are visualized as colored halos with specific color/intensity rules, and it recommends parameter values for large queries (network_flavor='confidence', required_score ~700). It does not add information for every parameter, but the added guidance is substantive.

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 verb and resource: 'Retrieves a stable URL to an interactive STRING network for one or more proteins.' It explains the single-protein and multi-protein behavior clearly, but does not explicitly differentiate this tool from sibling network tools like string_visual_network or 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 gives operational guidance for parameters (when to lower required_score, how to handle large queries with network_flavor and required_score), which implies usage context. However, it never states when to choose this tool over sibling STRING tools or when not to use it; the guidance is about invocation details rather than tool selection.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are present, so the description carries the full burden, and it does meaningful work: it discloses the single-species limitation (and that it cannot rank species by protein count), warns that results reflect annotation depth and should be interpreted cautiously, and offers a query-simplification fallback. It does not mention permissions, rate limits, or read-only status, but for a retrieval tool these matter less than the interpretation caveats it does provide.

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 usage guidance is front-loaded and well-organized, but the description ends with an enumeration of output fields (category, term, description, proteinCount, preferredNames, etc.) that duplicates what the existing output schema already declares, adding length without new value. Removing that block would make it tighter and more focused.

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?

With an output schema present, the return values are covered, and the description supplies the remaining context an agent needs: species constraint, term-format conventions, interpretation caveats, and a no-results fallback. It is nearly complete; the only real gap is the absence of any pointer to competing sibling tools for related tasks like enrichment.

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%, so the baseline is 3; the description goes beyond the schema by giving real guidance on how to format term_text (BRENDA tissue nomenclature, omit the word 'tissue'), which is not stated in the schema. That extra syntax/format guidance lifts it above baseline, though it does not clarify detail_for_term's interaction with the omitted fields beyond what the schema already says.

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?

States a specific verb and resource ('Retrieve proteins annotated with a functional term or descriptive text') plus an explicit scope constraint ('in a single species'), and enumerates the queryable categories (tissues, compartments, diseases, processes, pathways, domains). It is clear what the tool does, but it never names a sibling (e.g. string_enrichment or string_functional_annotation) to disambiguate, so it falls short of a 5.

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?

Gives concrete usage context: the categories you can query, the warning to run the tool separately per species for cross-species comparisons, and a fallback ('If no results are found, try simplifying the query'). It also supplies a domain convention for tissue queries (BRENDA nomenclature, omit the word 'tissue'). No explicit 'do not use this when…' or named alternative is given, so it is a strong 4 rather than a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses useful constraints: up to 100 taxon IDs separated by %0d, results limited to top 50 matches per query, and a specific fallback behavior for unmatched species. It does not cover authentication needs, rate limits, or read-only status, but for a query tool the disclosed limits and fallback are substantial.

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 bullet-structured and front-loads the core purpose before usage details. It is mostly efficient, though the bullet about resolving NCBI taxon IDs to scientific names is somewhat redundant with the opening sentence and creates minor ambiguity about return values. Overall it is appropriately sized and 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?

Given the simple one-parameter schema, existing output schema, and lack of annotations, the description supplies the key contexts an agent needs: when to use it, input limits, result limits, species-vs-clade behavior, and a fallback for missing species. Return values need not be explained because an output schema is present.

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 baseline is 3. The description adds a meaningful constraint beyond the schema: it accepts up to 100 taxon IDs separated by %0d. It also reinforces that multiple queries should use taxon IDs rather than free-text names, which helps an agent choose the correct input form.

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 verb and resource: search for species or clades available in STRING and return their NCBI taxonomy IDs. It also clarifies that the tool is used to obtain correct taxon IDs for other tools, making its role distinct from sibling tools. The added note about resolving NCBI taxon IDs to scientific names is slightly inconsistent with 'return their NCBI taxonomy IDs', but it does not obscure the primary 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 criteria: user asks which species or clades are present, or an agent needs a taxon ID to pass to other tools. It also states when-not: when the user asks for a species list, do not list clades. It names a concrete fallback tool and condition: invoke string_help with topic='missing_species' if 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.

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the output content (metadata fields) and includes an input example, but it does not explicitly state that the operation is read-only, whether it has rate limits, or any authentication requirements. The gaps are moderate for a query tool.

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 short, front-loaded, and structured into three brief sentences. The example input duplicates a schema example slightly, but overall it is efficient and easy to parse.

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 moderate complexity, full schema description coverage, and the presence of an output schema, the description is nearly complete for selection and invocation. It lacks explicit sibling differentiation, but the purpose and return metadata are sufficiently described.

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 input schema already documents all three parameters in detail. The description only restates that one or more protein identifiers are accepted and gives an example that duplicates the schema example. It adds no meaningful parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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 verb and resource: 'Maps one or more protein identifiers to their corresponding STRING metadata.' It also enumerates the metadata types returned, making the tool's purpose clear. However, it does not explicitly differentiate itself from sibling tools such as 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 clear usage context: 'useful for translating raw identifiers into readable, annotated protein entries.' This tells an agent when the tool is appropriate. It does not, however, mention when not to use it or name alternative sibling tools for overlapping tasks.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the core behavior: results are the most similar STRING protein(s) for a given species, ranked by sequence similarity, and input may be one or many FASTA records. It stops short of stating failure behavior (no match found), confidence/threshold semantics, or whether a fuzzy best-hit match is returned blindly, which for a similarity-lookup tool would be the most valuable remaining disclosure.

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?

Three sentences/tight bullets, front-loaded with the purpose and then the routing rule. No filler, and the most decision-relevant information (when to use it) comes last where it is 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?

With an output schema present, the description need not explain return values, and the schema covers both parameters, so the description is close to sufficient. The only gap is that a similarity-based matcher can return an approximate hit, and nothing here tells the agent how to interpret or validate that result.

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 both 'species' and 'sequences' are already fully documented in the schema. The description restates the FASTA/multi-sequence capability but adds no syntax, default, or format detail beyond what the schema provides; baseline 3 applies.

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?

States a specific verb (searches) plus the resource (STRING database) and the discriminating input modality (amino acid sequences) that separates it from identifier-based siblings. It also names the specific alternative, string_resolve_proteins, so an agent can route correctly without opening schemas.

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?

Explicit routing rule: 'Use this when the protein identifier is unknown or unresolvable by string_resolve_proteins.' This gives both the condition that selects this tool and the alternative it replaces, which is exactly what is needed among 17 sibling tools.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: output is an image URL, positive/negative numeric values map to blue/red halos with intensity scaled by magnitude, and parameter values should mirror related STRING tools. It omits things like rate limits or permission needs, but for a read-only retrieval tool this is largely 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?

Front-loads the core purpose and scopes single- vs multi-protein behavior early, then uses bullets for the numeric-value rules and large-query advice. Slightly long and the color-mapping detail is a bit verbose, but every section maps to a real decision the agent must make.

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?

A 9-parameter tool with an output schema benefits from the description covering the query syntax, visualization semantics, scaling guidance, and cross-tool consistency. Combined with the schema's own parameter docs, an agent has everything needed to invoke it 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 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema: the numeric-value-per-protein syntax and its visualization meaning, the guidance to preserve those values, and tuning advice for required_score and network_flavor at scale. It doesn't cover every parameter, but it enriches the most agent-relevant ones.

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?

States a specific verb and resource ('Retrieves a URL to a STRING interaction network image') plus the scope (single vs. multiple proteins). It is distinguishable from siblings like string_network_link (interactive page) and string_enrichment_image_url, and it explicitly routes the user to the interactive-page 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?

Gives concrete conditional guidance: lower required_score when few interactions appear, use network_flavor=confidence and higher required_score for >100 proteins, and preserve numeric values in the query. It stops short of an explicit when-not/alternative comparison against sibling tools, but the practical usage rules are clear.

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