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

Annotations already declare readOnlyHint and idempotentHint. The description adds that the guidance is static and works even when the API is unreachable, which is valuable context beyond annotations—indicating it is a precomputed reference, not a live query. No contradiction found.

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 two concise sentences, front-loading the core content (vocabulary and usage) and ends with a practical guarantee (works offline). Every sentence earns its place; no redundant or verbose language.

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 tool with no parameters, no output schema, and read-only/idempotent annotations, the description fully covers what the tool does, what it covers, and why it is reliable. An agent knows exactly when and how to use it, and no additional operational details are needed.

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?

There are zero parameters, so the schema coverage is 100% and the baseline score of 4 applies. The description appropriately adds nothing about parameters, and no parameter-specific guidance is needed.

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 explains the graph's vocabulary and how to use the tool set, listing specific topics (edge kinds, interaction types, direction semantics, orientation, recommended call flow). This distinguishes it from data-retrieval siblings and gives a precise, actionable 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?

It implies usage as an onboarding/reference tool ('how to use these tools', 'recommended call flow') and notes it works even if the API is unreachable, suggesting it is always safe to consult. However, it does not explicitly say 'use this before other tools' or list when not to use it, which would strengthen 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's burden is lower. It adds useful context: edges carry biological orientation and the graph is directed. However, it does not disclose other behavioral traits like error handling, data volume, or response structure beyond the output 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 two concise sentences that front-load the main purpose and immediately provide essential format details and a behavioral note (directedness). No redundancy or fluff 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 simple 2-parameter tool with an output schema and safety-oriented annotations, the description is largely complete. It could explicitly state that 'symbol' is a protein identifier, but this is heavily implied by 'a protein's interactome'.

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 0%, so the description must compensate. It explains the 'format' parameter's allowed values (tsv, sif, graphml) and their typical use cases, but it does not describe the 'symbol' parameter beyond the implied protein context, leaving it under-specified.

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 a specific verb ('Export'), resource ('a protein's interactome'), and purpose ('for external tools'). It also lists concrete output formats (tsv, sif, graphml) and notes directedness, distinguishing it from sibling tools like get_interaction or list_interactions that retrieve data directly.

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 this tool is for exporting interactome data for external analysis, but it does not explicitly state when to prefer it over alternatives, nor does it mention when not to use it. The context (format options and directedness) partially informs usage, but explicit routing is missing.

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?

Annotations already cover read-only and idempotency, so the description adds value by explaining the ranking criterion (supporting evidence) and the tool's role as an entry point. It discloses that results are ranked and curated, going beyond the structural hints. No contradiction with annotations.

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?

Two concise sentences, with the key 'curated entry point' and ranking logic front-loaded. There is no wasted wording, and every phrase contributes to understanding the tool's purpose and 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?

For a zero-parameter tool with no output schema, the description is sufficiently complete: it conveys the selection criteria and the overview nature. It doesn't specify the output format (e.g., list of IDs vs. details), but that is a minor gap for an overview tool. Overall, an agent can call it correctly based on this description.

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?

There are zero parameters, so the description is not required to explain them. The baseline is 4, and the description doesn't mislead or require compensation since schema coverage is trivially 100%. No additional parameter semantics are needed.

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 a curated entry point of best-evidenced interactions ranked by supporting evidence. It distinguishes itself from siblings like get_interaction or list_interactions by emphasizing the 'curated' and 'overview' nature. While it doesn't use an explicit verb like 'returns,' the intent is 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 phrase 'Good for a quick, strong overview' implies when to use it (initial exploration) but does not explicitly name alternatives or state when not to use it. It lacks the direct comparison seen in high-quality definitions, such as 'use search_calls_extensive instead.' The guidance is present but underdeveloped.

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?

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds value by describing the enriched contents (mechanism prose, direction, per-function effects, kinetics, evidence) and explaining the behavioral effect of the query parameter on source/target orientation. No contradictions with annotations.

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?

Two sentences, front-loaded with the core purpose, then covering contents and query behavior. No unnecessary words. The structure makes the most important information immediate.

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 no output schema, the description lists the main content types of the record, providing a rough expectation of the return. It also covers the optional query behavior. The only minor gap is the lack of comparison to get_interaction_between, but the purpose is clear enough to disambiguate. Overall, it is complete for a straightforward fetch-by-id 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 0%, so the description must compensate. It explains the query parameter well, specifying that it orients source/target. For interaction_id, only the phrase 'by id' is given, which is adequate for a self-explanatory identifier but lacks format or constraints. The description partially covers the parameters but does not fully compensate for the lack of schema descriptions.

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

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

The description clearly states the verb (get), the resource (a single interaction), and the discriminator (by id). This distinguishes it from siblings like list_interactions (which lists multiple) and get_interaction_between (which finds interactions between specific proteins). The phrase 'full enriched record' also signals comprehensive detail.

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 implicitly tells the user when to use the tool: when you have an interaction_id and want the complete record. It also provides clear guidance on the optional query parameter, explaining how it reorients the record. However, it does not explicitly contrast with get_interaction_between or other alternatives, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds meaningful behavioral detail not in annotations: the orientation from `a`, implying a directional relationship (A affects B). It also hints at possible multiplicity with 'interaction(s)'. This goes beyond the schema and annotations without contradicting them.

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 only two sentences. The first sentence states the core function with the orientation detail front-loaded. The second sentence provides a practical use case and an alternative. There is zero fluff, and every word contributes to understanding the tool's purpose and usage.

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 tool with two string parameters and no output schema, the description covers the basics: purpose, usage case, and orientation. However, it does not explain what the returned interaction(s) look like (structure, format, or whether it returns a list). It also fails to differentiate from the closely named sibling get_interaction, which could lead to confusion. Given the presence of multiple interaction-related siblings, this is a notable gap that reduces completeness.

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 has 0% description coverage, so the description must compensate. It explains that both parameters are 'named proteins' and clarifies that `a` is the source/origin of the orientation. This gives useful semantic meaning to the otherwise bare string parameters. However, it does not specify identifier format (e.g., gene symbol vs. UniProt ID) or validation rules, so it is not fully comprehensive but adequate for basic usage.

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 function: returning the interaction(s) between two named proteins, oriented from `a`. It uses a specific verb ('get') and resource ('interaction between two proteins'), and differentiates from a sibling by explaining why this tool is preferred over pulling get_protein. This is unambiguous and distinguishes it from other 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 explicitly gives a usage case: 'Use this for "what does A do to B" in one call' and points to an alternative (get_protein) as a less efficient method. However, it does not mention other closely related siblings like get_interaction or list_interactions, so the guidance is not exhaustive. It provides clear context and a reason to use this tool, but lacks exclusions for all alternatives.

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?

Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral context by specifying the exact data composition (node, ancestors, children, interactions), which helps the agent understand the response shape. No contradiction detected.

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, concise sentence that front-loads the core purpose and then details the scope. Every phrase earns its place 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 read-only annotation and the straightforward single-ID lookup, the description adequately conveys what is returned. It omits error handling or not-found behavior, but for this simple tool the provided information is largely 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?

Schema description coverage is 0%, so the description must compensate, but it only says 'by id' which adds little beyond the parameter name 'pathway_id'. There is no explanation of the ID format, source, or any constraints, leaving the agent with minimal 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 clearly states the tool retrieves a single pathway by ID and enumerates what is returned (node, ancestors, children, interactions). This is specific and action-oriented, and the 'pathway-first' phrase helps position it among other graph access 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 implies this is the primary entry point when starting from a pathway, but it does not explicitly mention alternatives or conditions for when not to use it. The sibling get_pathway_tree is likely a related option, yet no routing guidance is provided.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral detail: the response is a flat list requiring client-side assembly via parentId, and the data includes canonicalPathwayId fields. This goes beyond the annotations without contradicting them.

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 three sentences, each earning its place: the first defines the output, the second explains assembly, and the third gives the primary use case. Information is front-loaded and there is no filler or verbose phrasing.

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 parameterless tool with no output schema, the description fully covers what an agent needs: it indicates the output is a flat node list, explains how to reconstruct the tree (via parentId), and clarifies the intended purpose (mapping canonicalPathwayId to names). Nothing essential 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?

The tool has zero parameters, so the schema provides no parameter documentation. Per the rubric, a 0-parameter tool gets a baseline of 4, and the description does not need to add anything. No redundancy or missing information exists to penalize.

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 returns 'the full pathway scaffold as a flat node list', specifying both the resource (pathway scaffold) and the form (flat node list). It also mentions the key field (parentId) and a distinct use case (resolving canonicalPathwayId), making it easy to distinguish from siblings like get_pathway or get_highlights.

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 a concrete use case: 'Use this to resolve the canonicalPathwayId values returned on interactions into human-readable pathway names.' This clearly tells an agent when to invoke it. It does not explicitly mention alternatives or exclusions, but the specific purpose effectively implies it is for tree/name resolution rather than other pathway operations.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description goes beyond annotations by explaining the compactness rationale ('~700K tokens for a hub protein'), listing the fields returned (metadata, counts, pathway roots, headline rows per interaction), and explicitly stating what is omitted (heavy per-edge mechanism and evidence prose). This gives the agent crucial expectations about response size and content. No contradiction with annotations.

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 about 140 words, well-structured with a clear opening statement of purpose, followed by a list of return contents, an explicit note on omitted data for token efficiency, and a direct drill-down instruction. Every sentence adds value; no fluff. The crucial scope note ('compact overview', 'main entry point') 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?

For a simple tool with one parameter and no output schema, the description is mostly complete: it details the return structure (fields per row, counts, pathway roots), notes what is omitted, and gives a follow-up action. The only major omission is the definition of `symbol`, which is critical for correct invocation. Lacking that, completeness is reduced, but the rest is well covered.

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 has one required parameter `symbol` with only a title 'Symbol' and no description. Schema description coverage is 0%, so the tool description must compensate. It does not. The description never explains what `symbol` stands for (e.g., gene symbol, UniProt ID, common name), leaving the agent to guess. This is a critical gap for a single-parameter tool.

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 purpose: 'Overview map for one protein, the main entry point.' It specifies the resource (protein) and the action (get overview). It further distinguishes itself from siblings by explaining it returns a compact overview and explicitly names the sibling `get_interaction` for deeper detail. This is specific and 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 provides clear usage context: it is the 'main entry point' for exploring a protein. It explicitly directs the agent to `get_interaction(id)` for drilling into edge details ('mechanism + kinetics + evidence'). This covers the most relevant alternative. However, it does not mention other sibling tools like `search_proteins` or `get_pathway_tree`, so guidance is not exhaustive, but sufficient for common use cases.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds the behavioral trait 'headline-only list,' which implies condensed output, and mentions it is 'lighter' than get_protein. However, it does not describe pagination behavior, exact response structure, or error conditions. With strong annotations, a 3 is appropriate – it adds some context but not rich behavioral detail.

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 efficient, packing purpose, parameter definitions, and usage context into a few lines. The main purpose is front-loaded, and the rest is organized clearly. It earns its length without fluff, though it could be slightly more scannable by separating parameter explanations into a list.

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 list tool with strong annotations and a well-explained purpose, the description provides enough to call it correctly. It covers filtering, sorting, and the 'headline-only' nature of output. It lacks specific return format or pagination details, but that is acceptable given the tool's simplicity and the presence of get_interaction for deeper detail.

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 0%, so the description must explain parameters. It explicitly defines kind (activates|inhibits|binds|regulates), type (direct|indirect), pathway (substring), min_evidence (minimum papers), and sort (evidence|functions|partner). It does not explain limit, order, or symbol, but symbol is the required protein identifier and limit/order are common and inferable. The explanation of the key filtering parameters is strong, so a 4 is justified.

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 a specific verb and resource: 'Filtered, sorted, headline-only list of a protein's interactions.' It explicitly contrasts with siblings by calling itself 'Lighter than get_protein' and directing drill-in to get_interaction, so the agent knows exactly what this tool does and how it differs.

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 it for targeted questions' with an example, and names the alternative 'get_protein' and the follow-up 'get_interaction(id)'. It also explains the filter parameters (kind, type, pathway, min_evidence, sort) which tell the agent how to tailor the query, leaving no ambiguity about 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?

Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds behavioral detail by specifying the output contains 'plain-language meanings and live counts' and that it's a controlled vocabulary, giving an agent insight into the return contents without needing an output 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 two sentences, front-loaded with purpose and immediately followed by usage guidance. Every word adds value; no fluff or 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?

For a zero-parameter, read-only vocabulary listing tool, the description fully covers what the agent needs: what it returns (meanings, counts), what domains it covers (edge kinds, interaction types, directions, mechanisms), and when to use it (before filtering). No output schema is needed because the description already characterizes the response.

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 has zero parameters, so the description carries no parameter burden. Baseline of 4 applies because there is nothing to compensate for; the description appropriately focuses on the tool's purpose rather than 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 clearly states the tool lists a controlled vocabulary with meanings and counts for edge kinds, interaction types, directions, and mechanisms. It uses a specific verb ('list') and resource ('interaction types'), and the context differs from siblings like list_interactions (which likely lists actual interactions) and describe_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?

The description explicitly instructs 'Call this before filtering so you use valid values,' providing a clear when-to-use scenario. It implies this is a prerequisite for other operations, which is actionable guidance for an agent.

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?

Annotations already provide readOnlyHint and idempotentHint, and the description adds behavioral details: case-insensitive prefix matching and the result contents (HGNC id and description). There is no contradiction, and the description adds context beyond annotations, though it doesn't discuss pagination or 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?

Two concise sentences, front-loaded with the core action and followed by result and usage advice. No redundant 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?

The description covers the search semantics, result fields, and recommended workflow. It does not explicitly describe the limit behavior or potential empty results, but these are minor for a search tool. Given no output schema, the return description is adequate.

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

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

The schema has 0% description coverage, so the description must explain the parameters. It implicitly explains q as a symbol prefix but does not explain the limit parameter or its effect. This is a partial contribution, but not fully compensating for the schema 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 states a specific verb ('Search'), a specific resource ('proteins'), the method ('by symbol prefix'), and case-insensitivity. It also mentions what it returns (HGNC id and description) and distinguishes it from the sibling get_protein by explicitly saying to use this first and then call get_protein.

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 instructs the agent to use this tool first to resolve a protein of interest, then call get_protein. This provides a clear when-to-use scenario and names the alternative tool, fulfilling the usage guideline criteria.

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