raras

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

Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral context by emphasizing the tool is informational and not diagnostic, which is important for safe use. No other behavioral traits are disclosed, but the bar is lowered by the existing 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 extremely concise, consisting of two short sentences. The main purpose is front-loaded, and every sentence adds value or context. No redundant or vague wording.

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 has 3 parameters (one required) and no output schema, the description lacks information on how to structure the case_description or how the limits affect results. It is incomplete for a tool intended for complex medical analysis.

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

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

The input schema has 3 parameters with 0% description coverage, and the description does not explain any parameter. It neglects to describe the required case_description or the optional limits, providing no additional meaning beyond the schema.

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

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

The description clearly states the tool maps clinical cases to candidate diseases and relevant literature in one call ('Caso clínico → doenças candidatas + literatura relevante em 1 chamada'). It distinguishes from siblings by combining both functions, which many siblings do separately.

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 includes a disclaimer ('Apenas informativo, nunca diagnóstico') providing some usage context, but does not explicitly state when to use this tool versus alternative sibling tools or mention exclusion criteria.

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?

Discloses key behaviors: returns multi-hop paths with citable provenance, refuses if no path, never invents. The readOnlyHint annotation confirms read-only nature, and the description adds detail beyond that.

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?

Concise paragraph with front-loaded purpose and clear examples. No filler, but could benefit from brief parameter enumeration.

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

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

Covers the core function and behaviors well, but misses documentation of optional parameters. Output schema exists, so return format is covered elsewhere. For a tool with moderate complexity, this is adequate but not complete.

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

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

The description only covers the 'query' parameter implicitly via examples. The optional parameters hpo_ids and max_hops are not mentioned, leaving their purpose and usage unclear despite 0% schema coverage.

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

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

Clearly states the tool's purpose: given a question about biomedical relations, it returns multi-hop evidence paths with citations. Examples ('why does gene X associate with disease Y?') make it concrete. Distinguishes from sibling search and analysis tools by focusing on explanatory reasoning.

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

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

Explicitly states when to use (for 'how/why' questions) and what it does when no path exists (refuses, never invents). However, it does not explicitly contrast with siblings or provide alternative tools for simple lookups.

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, and the description does not disclose any behavioral traits such as read-only nature, API calls, or side effects. It fails to inform the agent about the tool's behavior beyond its basic function.

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

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

The description is very short but not overly concise; it is adequate in length but lacks necessary detail. It is front-loaded with the core idea but could include more structured information about parameters.

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 has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the parameters' roles, required inputs, or expected output, leaving the agent underinformed.

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

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

With 0% schema description coverage, the description adds minimal value. It mentions a Brazil filter, which corresponds to the 'in_brazil_only' parameter, but does not explain 'orphaCode' or 'limit', leaving their meanings unclear.

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 'Active trials with Brazil filter', clearly indicating the resource (active trials) and a specific filter (Brazil). It is concise and directly conveys the tool's purpose, though it does not differentiate from sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives or specific contexts. The description only mentions a Brazil filter, offering no exclusions, prerequisites, or comparisons to 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?

No annotations are present, so the description must disclose behavioral traits. It does not mention what the tool returns (e.g., list of community names, contact info), whether it is a read-only operation, or any side effects. The agent has no insight into the tool's 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 description is extremely short but under-specified. While conciseness is valued, this lacks necessary information. The structure is not helpful; it provides no actionable guidance.

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

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

Given the complexity of the domain (rare disease communities), no output schema, and no annotations, the description is severely incomplete. The agent cannot reliably select or invoke this tool based on the current definition.

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

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

With 0% schema description coverage, the description adds no meaning beyond the schema fields. The description does not explain the purpose of orphaCode (e.g., Orphanet code) or limit (number of communities to return). The agent lacks semantic understanding of 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 'Comunidades FEBRARARAS por doença.' is vague and appears to be Portuguese with a possible typo. It does not clearly state that the tool finds patient communities by disease, leaving the purpose ambiguous. The tool name and orphaCode parameter suggest a search by disease code, but the description fails to confirm this.

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

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

No usage guidelines are provided. The description does not indicate when to use this tool versus its siblings like search_diseases or find_similar_diseases. There is no guidance on context, prerequisites, or 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?

With no annotations provided, the description fails to disclose behavioral traits such as read-only status, side effects, or authorization needs. It only repeats the core purpose, leaving a significant gap.

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

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

The description is extremely concise: two sentences, front-loaded with action and context, no superfluous words.

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 lack of annotations and output schema, and two parameters (one required), the description is too brief. It omits return format, pagination, and any behavioral details needed for full understanding.

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%, and the description only hints at hpo_ids via 'IDs HPO' without explaining limit or constraints. It adds minimal semantic value beyond the schema types.

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 matches using HPO IDs for differential diagnosis, providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like find_phenotypically_similar or search_diseases.

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 suggests use for differential diagnosis, giving a clear context, but lacks explicit when-not-to-use instructions or alternatives, leaving the agent to infer.

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, and the description only mentions embeddings and fallback, without disclosing read-only nature, permissions, or any side effects.

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

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

The description is very short (one line), but fails to provide necessary details, making it insufficient rather than concise.

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 three parameters and no output schema, the description lacks essential information about return values, parameter formats, and use cases.

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

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

Schema description coverage is 0%, yet the description adds no explanation for the three parameters (orphaCode, limit, min_score) beyond what the names imply.

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 it finds literature related to a disease via embeddings, but does not distinguish it from the sibling tool 'search_papers_semantic' which likely performs a similar function.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for use.

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. The description adds context about the precomputed and explainable nature (number of common phenotypes), enhancing transparency without contradiction.

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 effectively convey purpose, method, and complementarity with zero wasted words.

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

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

Given the presence of an output schema and annotations, the description sufficiently covers key aspects for a search tool. It could add parameter details but the output schema likely handles return structure.

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 description should compensate. It does not explain the meaning of orphaCode or limit beyond what is in the schema, leaving a gap for agent understanding.

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

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

The description clearly states the tool finds diseases with similar HPO phenotype profiles using precomputed simGIC, and distinguishes itself from the semantic sibling find_similar_diseases.

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 notes it complements find_similar_diseases (semantic), guiding the agent when to use this tool over the alternative.

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 must disclose behavioral traits. It only mentions that CNES is included, but fails to indicate read-only status, required permissions, or behavior when multiple filters are combined. This is insufficient for an agent to understand side effects or constraints.

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

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

The description is very concise (single phrase), which is appropriate for simplicity, but it lacks necessary detail. It is efficient in length but fails to convey sufficient 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 tool with 3 parameters, no output schema, and 0% schema coverage, the description is incomplete. It does not describe the output structure beyond CNES, nor does it explain the interaction between filters or any default behavior.

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?

Despite 0% schema description coverage, the description adds minimal parameter meaning. It references 'doença' (disease) and 'UF' (state) but does not explicitly link them to orphaCode and state parameters. It does not explain the limit parameter or the meaning of CNES in relation to the output.

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 'Centros por doença e/ou UF, com CNES' clearly indicates the tool retrieves reference centers filtered by disease and/or state, and includes CNES codes. It effectively distinguishes from sibling tools like find_diseases or find_active_trials, which address different resources.

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?

No guidance provided on when to use this tool versus alternatives. The description does not mention any prerequisites, typical use cases, or scenarios where other tools would be more appropriate.

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, and the description does not disclose behavior such as performance, limitations, or what the output contains. The phrase 'SOTA' is uninformative. This is a significant gap for a tool with no structured 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 extremely concise but at the cost of informative content. It is a single phrase that does not earn its place; it is too brief to be useful.

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 low complexity (2 params, no output schema), the description is still woefully incomplete. It does not explain return format, usage context, or behavior, leaving the agent without critical information.

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

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

The description adds no meaning to the two parameters (orphaCode and limit). With 0% schema description coverage, the description completely fails to clarify what each parameter does or how to use them.

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

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

The description 'Vector similarity via embeddings SOTA' implies the tool finds similar diseases using vector embeddings, but it is vague and uses unclear jargon. It does not explicitly state that it takes an orphaCode and returns similar diseases, which is needed for clear understanding.

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?

No guidance is provided on when to use this tool versus siblings like 'find_phenotypically_similar' or 'search_diseases'. The description lacks context for appropriate usage.

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 must fully disclose behavior. It states that the tool returns phenotypes, genes, SUS, trials, and clinical description, implying a read operation. But it lacks details on authorization, rate limits, or whether the data is filtered or exhaustive. The description provides minimal behavioral context beyond the data categories.

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

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

The description is very short (one sentence) and lists content areas separated by commas. It is concise but lacks structure; grouping or formatting would improve readability. The sentence is front-loaded with content but could be more structured as a bullet list or with clearer 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?

Given the tool's complexity (multiple data types like phenotypes, genes, trials) and the absence of an output schema, the description should provide more detail on the relationships between these data items and the response format. It only lists categories without explaining how they are organized or what to expect. This is insufficient for an agent to fully understand the tool's output.

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 single parameter 'orphaCode' has only a name and pattern in the schema, with 0% schema description coverage. The description does not explain what an 'orphaCode' is, how to obtain one, or its format beyond digits. This forces the agent to infer meaning from the tool name or external knowledge, which is insufficient.

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 lists specific content (HPO phenotypes, genes, SUS, trials, clinical description) that the tool provides, clearly indicating a comprehensive disease detail retrieval. The name 'get_disease_detail' also clarifies the verb and resource. However, it could more explicitly state the action and why it differs from siblings that focus on subsets of these data.

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?

No guidance is provided on when to use this tool versus alternatives. Siblings like 'find_active_trials' or 'find_phenotypically_similar' might be better for specific queries, but the description does not mention when or why to choose this tool. Weak usage context.

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 indicate readOnlyHint=true and openWorldHint=false. The description adds the context of the 'never invent' rule but does not disclose additional behavioral traits such as error handling, rate limits, or authentication needs.

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. The first lists the content delivered; the second emphasizes a rule. Both are relevant and front-loaded. No unnecessary words, though the second sentence could be more directly useful.

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 simplicity (one parameter, output schema present), the description covers intended content (sources, PMIDs, verification status). However, it lacks usage prerequisites (e.g., disease must exist) and parameter explanation, making it adequate but not thorough.

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

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

The input schema has one required parameter (orphaCode) with no description. The only semantic clue is 'de uma doença', implying orphaCode identifies a disease, but it fails to explain what orphaCode is or how to obtain it. With schema coverage at 0%, the description should offer more.

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 cross-references (Orphanet, MONDO, etc.), verification status, and PMIDs for a disease. The verb 'get' is implied, and it distinguishes from siblings like 'get_disease_detail' by focusing on evidence/cross-references. However, it could be more explicit about the action.

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?

No explicit guidance on when to use this tool versus alternatives like 'get_disease_detail' or 'find_papers_for_disease'. The phrase 'a base da regra nunca inventar' hints at fact-checking but does not provide practical usage context.

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 must carry the full burden of behavioral disclosure. It implies a read operation but does not mention any side effects, performance implications, or restrictions. The description is insufficient for transparency.

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

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

The description is very concise with a single phrase. It is front-loaded and uses no unnecessary words, but it is arguably too brief to be fully informative.

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

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

Given no output schema and no parameters, the description should elaborate on which counts and metrics are returned (e.g., node count, edge count). It does not, leaving the tool's output underspecified.

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

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

The input schema has 0 parameters, so the description is not required to clarify parameters. The description adds meaning by indicating the output is counts and metrics, which goes beyond the empty schema.

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

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

The description 'Contagens e métricas do dataset.' clearly indicates the tool provides counts and metrics of the dataset, which is a specific verb+resource. However, it does not differentiate from sibling tools that might also report metrics, such as get_sus_coverage, which limits clarity.

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?

No guidance is given on when to use this tool versus alternatives. The description lacks any context for appropriate usage or exclusions.

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?

Beyond annotations (readOnlyHint=true), the description adds critical behavioral context: the output is hypotheses only, never clinical recommendations, and each is traceable via gene and disease. This prevents misuse.

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 succinctly convey what the tool does and important caveats. No redundant words, and key information (hypotheses, traceability, non-clinical) is front-loaded.

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

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

Given the output schema exists, the description sufficiently sets expectations: it covers input (implicitly disease via Orpha code), output nature (hypotheses, traceable), and usage warnings. Parameter count is low, so completeness 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?

Schema description coverage is 0%, but the description does not explain the 'orphaCode' parameter or its format. The term 'orphaCode' is implied by the disease context but not explicitly defined, leaving the agent to infer meaning from the tool name.

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 generates drug repositioning hypotheses based on gene associations (guilt-by-by-association). It specifies the resource (candidates for repositioning) and distinguishes itself from siblings by focusing on hypotheses for investigation, not clinical recommendations.

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

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

The description implies usage when seeking drug repositioning hypotheses via gene sharing. It emphasizes these are investigational, not clinical, but does not explicitly contrast with sibling tools or state when to avoid.

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?

The description adds value beyond annotations by noting the provenance (number of publications) and the closed-world nature (only extracted relations). However, since readOnlyHint and openWorldHint are already set, the behavioral disclosure is adequate but not enhanced beyond basic traits.

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

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

The description is concise with two sentences, front-loading the main function. It avoids unnecessary detail and is efficiently structured.

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

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

Given that an output schema exists, the description does not need to explain return values. However, with 0% schema coverage, it inadequately explains the input parameters (especially orphaCode). The tool is simple, but the description leaves gaps for a new user.

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. It explains the predicate filter but does not describe the required orphaCode parameter (the disease identifier). Moreover, the listed predicates in the description (6) are incomplete compared to the schema enum (8), missing positive_correlation and negative_correlation.

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 typed relations (associate/treat/cause/inhibit/stimulate/prevent) between a disease and genes/drugs from biomedical literature, with publication counts. It is specific and includes the resource (PubTator3). However, it does not explicitly distinguish itself from siblings like explain_relation or get_evidence, leaving some ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives such as explain_relation or find_papers_for_disease. The description only mentions filterability by predicate but lacks context for appropriate usage.

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?

Beyond the existing annotations (readOnlyHint, openWorldHint), the description adds behavioral details: the tool returns updates from specific evidence sources and is designed for stateless polling. 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 concise sentences in Portuguese, front-loaded with purpose and usage. No redundant information; every sentence adds value.

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

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

Given the existence of an output schema and the tool's simplicity, the description adequately covers purpose, data sources, and usage pattern. It could mention that results are scoped to days and limit, but the schema covers parameter details.

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

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

Schema description coverage is 0%, so the description must compensate. It partially explains the 'days' parameter via 'nos últimos N dias' but does not describe 'limit'. It adds context about evidence sources but not parameter-specific semantics.

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

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

The description clearly states it returns diseases with recent new evidence from specified sources (authorship, PubTator3, Open Targets, verification) in the last N days. It uniquely positions this tool as a polling mechanism for updates, distinguishing it from sibling search and detail 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 recommends polling to track changes as a stateless substitute for subscriptions, providing clear context on when to use. However, it does not explicitly list when not to use or name alternative tools, which is acceptable given the sibling list.

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. The description adds context about the log's content (agent activities) but does not contradict annotations or disclose additional behavioral traits like safety or rate limits.

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

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

The description is a single, focused paragraph that efficiently conveys the purpose. It could be slightly more concise but is well-structured.

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

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

Given the single parameter and existing output schema, the description adequately explains the tool's purpose and content. It could mention the parameter briefly for 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?

Schema coverage is 0% (no descriptions for properties). The description does not mention the orphaCode parameter or provide any guidance on its usage or format, leaving a significant gap.

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

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

The description clearly states the tool provides a chronological record of autonomous agent activities for a specific disease, listing examples like authorship, literature mining, and genetic evidence. This distinguishes it from sibling tools like get_disease_detail or get_evidence.

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 the tool is for reviewing proof of continuous study by the digital twin, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions.

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 indicate readOnlyHint=true and openWorldHint=false, so the description adds limited behavioral context beyond stating the return elements. It does not contradict annotations and provides sufficient transparency for a read-only schema retrieval 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 consists of two short sentences with no redundant information. The first sentence describes the output, and the second provides a usage tip, making it highly concise and well-structured.

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

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

Despite lacking an output schema, the description clearly states what the tool returns (node labels, relationship types, property keys). Given the tool's simplicity (no parameters, read-only), the description is complete and sufficient for an AI agent.

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

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

The input schema has no parameters, and schema coverage is 100%. The description adds value by explaining what the tool returns, which is not covered by the empty schema, earning a baseline 4 for parameter semantics.

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

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

The description clearly states the tool returns node labels, relationship types, and property keys of the graph, which is a specific and distinct purpose. It differentiates itself from sibling tools like get_graph_stats by focusing on schema elements.

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 'Use antes de cypher_query' explicitly tells when to invoke this tool (before writing Cypher queries), providing clear context. However, it does not mention when not to use it or alternatives, slightly reducing the score from 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?

No annotations exist, and the description omits any behavioral traits (e.g., read-only, side effects, rate limits). The agent cannot infer the tool's 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 description is very short but not informative. It lacks a clear structure or purpose, making it more underspecified than concise.

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 lack of annotations, output schema, and parameter info, the description is completely inadequate for an agent to understand or use the tool correctly.

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

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

The sole parameter 'orphaCode' has no description in the schema or in the tool description. With 0% schema description coverage, the description adds no semantic value.

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

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

The description 'CEAF, SIGTAP, PNTN, nível de integração.' does not clearly state the tool's function. It lists acronyms without explanation, failing to specify a verb or resource.

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?

No guidance is provided on when to use this tool versus siblings. The description offers no context about appropriate 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?

With no annotations, the description should disclose behavioral traits. It only mentions full-text and filters, omitting details like pagination, case sensitivity, language support, or response format. Given the absence of annotations, this is insufficient.

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 extremely concise, with two sentences that convey the core functionality and available filters. No redundant information; every sentence earns its place.

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?

Despite being a 4-parameter tool with no annotations or output schema, the description covers the basic purpose and filters. However, it lacks details on output format, error handling, or integration context, making it only moderately 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 description coverage is 0%, so the description must add meaning. It clarifies the 'query' is for full-text search and the two boolean filters are for SUS coverage and active trials. However, it does not explain the 'limit' parameter beyond schema defaults.

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 'Full-text search in 10,468 rare diseases' with a specific verb and resource, and support for SUS/trials filters. It differentiates itself from siblings like find_similar_diseases (similarity search) and search_phenotypes (phenotype search).

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?

No guidance on when to use this tool versus alternatives such as find_similar_diseases or search_phenotypes. The description lacks explicit context for when to choose full-text search over other search methods.

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 mentions 'vetorial' (vector) search over a specific corpus, hinting at semantic search, but does not disclose whether it is read-only, destructive, or other behavioral traits like pagination.

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

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

Two short sentences are efficient and front-loaded. However, the description could be slightly more comprehensive without losing conciseness.

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

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

Given three parameters and no output schema or annotations, the description is thin. It does not explain return format, min_score semantics, or how to interpret results. Sibling tools may overlap, but no comparison is provided.

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. It only hints that query should be a clinical case, question, or symptoms, but does not explain limit or min_score 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 'Busca vetorial sobre 424k papers do PubMed', specifying a verb (search), resource (papers), and scope (vector search over a specific corpus). It distinguishes from siblings like search_diseases and search_phenotypes.

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

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

The description advises using this tool for 'caso clínico, pergunta ou conjunto de sintomas', which provides clear context. However, it does not explicitly state when not to use it or mention alternative 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?

Since annotations are absent, the description must disclose behavioral traits. It does not state whether the tool is read-only, requires authentication, has rate limits, or what happens on failure. The phrase 'returns IDs' is minimal and does not cover 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 description is very short (two phrases), which is concise but lacks structure. It front-loads the purpose but omits necessary details. For a simple tool, this could be acceptable, but it sacrifices completeness for brevity.

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 lack of output schema, annotations, and parameter descriptions, the description is inadequate. The agent cannot determine what the full response looks like, what errors might occur, or how to effectively use the tool.

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

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

Schema coverage is 0%, so the description must explain the parameters. It does not mention 'query' (required, minLength 2) or 'limit' (optional, default 15, maximum 50). The agent gets no clues about how to construct valid inputs.

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 looks up HPO terms in Portuguese or English and returns HP IDs, which is a specific verb+resource. It distinguishes from sibling tools like search_diseases by focusing on HPO. However, it is slightly vague about the exact operation (search vs. lookup by ID).

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?

No guidance on when to use this tool versus siblings (e.g., search_diseases, find_phenotypically_similar). No context about prerequisites or typical use cases is provided.

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