sniff-mcp

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

With no annotations, the description fully bears the burden. It discloses that the tool abstains honestly when lacking data, never guesses, returns cited answers, and notes limitations (educational not diagnostic, carrier != affected). This is comprehensive.

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 detailed but every sentence serves a purpose: stating core function, listing topics, explaining output format, giving usage guidance, and noting limitations. It could be slightly trimmed but remains efficient.

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

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

Given the presence of an output schema and the simplicity of the input (one string), the description covers all necessary aspects: input type, behavioral guarantees, output format, caveats, and usage guidance. No gaps remain.

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 'question' has 0% schema description coverage, but the description compensates by explaining the kind of natural-language questions accepted and the scope of topics. However, it does not specify format or constraints beyond that, which is a minor gap for a string parameter.

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: answering natural-language canine-genetics questions with grounded, cited answers. It lists specific topics covered (inherited diseases, breed risks, etc.) and explicitly distinguishes from sibling tools by directing structured lookups to variant/breed/gene tools.

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

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

The description provides explicit when-to-use guidance: 'USE THIS for any 'what is X / does breed Y get Z / human equivalent of W' question' and specifies when not to use it: 'use the variant/breed/gene tools for structured lookups by identifier.' This is exemplary.

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 provided, so description carries full burden. It details how the tool works: compiles question into typed query plan, runs deterministically, scores by weakest edge, returns hints with evidence tier (fact/computational/inferred) and citations, or abstains with demand signal. Also clarifies that answers are hypothesis-generating, not clinical claims, and describes the narrate option.

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 relatively long but well-structured with bold section headers and specific examples. Every sentence adds value, though some information (e.g., detailed output format) could be slightly condensed without losing clarity.

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

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

Given the complexity of the tool (edge-graph, multiple evidence tiers, output with plan/hints/abstain), the description covers all essential behaviors, usage contexts, and parameter details. Output schema exists, so detailed return format is appropriately included.

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 lacks descriptions for both parameters (coverage 0%). The description compensates by explaining 'question' is a free-form cross-species genetics question and 'narrate' (boolean, default false) adds a gated prose summary per hint. This adds significant 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's purpose: ask a free-form cross-species genetics question and get filtered hints. It distinguishes from sibling 'ask' by specifying this is for human-disease to dog-model queries, while 'ask' is for owner-facing questions.

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 best use cases (model-discovery, translational traversal) and gives example queries. Directly says when to use alternative ('Use `ask` instead for...'). Provides thorough guidance on when to invoke this tool.

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 provided, so the description carries the full burden. It describes the returned data and optional parameters but does not explicitly state read-only behavior, error handling, or prerequisites like genome build validity. The description is clear but lacks explicit safety disclosure.

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

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

Two sentences with no wasted words. The first sentence is dense but clear, and the second concisely explains optional parameters. All information is front-loaded and relevant.

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

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

Given the tool's complexity and the presence of an output schema, the description provides a solid overview of what is returned. It specifies the genome build (CanFam4) and optional tuning. Minor omissions include no mention of output format or error cases, but overall 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%, but the description adds meaning for 3 of 4 parameters: position format (example given), breed_context (effect explained), cross_breed_full (behavior described). top_n is not described, but defaults are noted. The description compensates well for missing 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 tool returns comprehensive variant information given a CanFam4 position, including frequencies, pathogenicity, gene context, diseases, and more. It distinguishes itself from sibling tools (e.g., variant_lookup, breed_variant_frequency) by being a one-call aggregator, marked as 'THE headline query'.

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?

Implied usage is for comprehensive variant info, and the description hints it's the primary query. However, no explicit when-not-to-use or alternative recommendations are given, though sibling tool names suggest alternatives for focused needs.

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 explains the metric and interpretation, which adds behavioral context beyond missing annotations. However, it does not disclose limitations, assumptions, or output format (though output schema exists).

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

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

A single sentence with a parenthetical clarification is concise and front-loaded. However, it might be too terse; could include more details without becoming verbose.

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

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

Given the tool has two parameters and an output schema, the description covers purpose and metric but omits interpretation details (e.g., range of values) and constraints (e.g., which breeds are valid). Adequate but not comprehensive.

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 meaning that the parameters are breeds and that the tool computes genetic distance, compensating for 0% schema coverage. However, it does not specify breed naming conventions or 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 computes genetic distance between two breeds using top-10-PC Euclidean distance, and interprets lower values as more genetically similar. It distinguishes itself from siblings like 'nearest_breeds' by explicitly being pairwise.

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 over alternatives such as 'nearest_breeds' or 'breed_summary'. No prerequisites or context provided for 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?

No annotations provided, and description does not disclose any behavioral traits (e.g., caching, limitations). It only states output content.

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?

Single sentence, no wasted words, front-loaded with key action and scope.

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?

Complete for a simple list tool with output schema; explains both content (breeds and frequencies) and scope (all 188 breeds).

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?

Zero parameters; baseline is 4. Description correctly implies no input 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?

Description uses specific verb 'List' and resource 'breeds', adds detail about output ('with breed-stratified frequencies'), and distinguishes from siblings like breed_summary and breed_variant_frequency.

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; given many sibling tools, explicit context would help.

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 no annotations are provided, the description carries full burden. It discloses the output fields and the filtering criteria for variants, and explicitly states the tool is descriptive (not evaluative). This is transparent about behavior, though it does not mention idempotency 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 two sentences, front-loaded with key content, and contains no filler. Every word 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 tool has a single parameter and an output schema exists, the description is fairly complete. It explains the selection criteria for variants and the fields returned, and warns that it is not a health ranking. It could be slightly improved by noting that the breed must match atlas breed names.

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 is only one parameter 'breed' of type string. With 0% schema description coverage and no enum values, the description should compensate by clarifying allowed values or format, but it does not. The description focuses entirely on output, not input 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 provides a breed profile with specific content: top damaging common variants (with explicit criteria ESM2<=-5 & breed AF>=5%), n_dogs, and breed group. It distinguishes itself from sibling tools like disease_links and breed_variant_frequency by emphasizing it is descriptive only, not a health ranking.

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 context by stating 'Descriptive only — not a health ranking,' which implicitly tells when not to use it (health ranking). However, it does not explicitly mention when to use this tool over alternatives like breed_variant_frequency or semantic_search, nor does it provide prerequisites.

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?

Without annotations, the description does a fair job explaining that it returns AF and rank for a variant or per-variant AFs for a gene. It does not disclose any permissions, error behaviors, or data freshness, but covers the core behavior sufficiently.

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 no waste—with the key information front-loaded. Every word 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 moderate complexity and the existence of an output schema, the description sufficiently explains the two operating modes and return values. It could elaborate on edge cases like missing breed, but overall it is complete for an AI agent to use the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explains the roles of breed, variant, and gene, but does not clarify mutual exclusivity or the format of the variant string. The description adds some meaning but leaves ambiguity about what happens if both variant and gene are provided.

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 'Breed-stratified allele frequency' and explains two modes (by variant or gene). It uses specific verbs ('Give', 'Returns') and distinguishes from sibling tools like variant_lookup by specializing to breed stratification.

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

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

Explicitly tells the agent to provide a breed and either a variant or gene symbol, which defines when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among siblings for non-breed-stratified queries.

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

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

No annotations exist, so the description carries the full burden. It discloses the tool is 'Educational, not diagnostic' and mentions output structure (source, atom_id). However, it does not discuss performance limitations, authentication needs, or what happens with invalid inputs.

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 four sentences and front-loads the purpose. However, it includes technical jargon ('fused OMIA disease layer as cited atoms') that may obscure meaning, and could be shortened without losing key information.

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

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

Given the tool's complexity (two input modes, no required parameters, no annotations), the description covers both input scenarios and sets expectations about output content and purpose. The existence of an output schema reduces the need to describe return values, so this 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 coverage is 0%, but the description adds significant meaning: it explains that 'disease' can be a name or an OMIA ID (with example 'OMIA:001870-9615'), and 'breed' can be a standard name (e.g., 'doberman_pinscher'). This fully compensates for the missing 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 tool provides disease or breed information from OMIA, listing specific outputs (genes, inheritance, human homolog, pathogenicity grade for disease; inherited conditions with carrier frequency for breed). It uses verbs like 'give' and distinguishes by input type, but does not explicitly differentiate from sibling tools like disease_links or gene_summary.

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

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

Usage is implied by describing what to input ('Give a disease ... or give a breed ...'), but no explicit when-to-use or when-not-to-use guidance is provided. Siblings suggest alternatives, but the description fails to direct users to the correct tool for their need.

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 fully discloses behavior: it returns a curated set of fields (mode of inheritance, causal genes, clinical signs, etc.), sources (OMIA, CC-BY), caveats (Dog-only, educational, not diagnostic), and conditional molecular links. No contradictions.

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

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

The description is a single paragraph containing all necessary information without redundancy. It is front-loaded with the primary mapping and lists outputs efficiently. Though dense, every sentence adds value. Slightly long but still concise for the amount of detail.

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

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

The description is fully complete for the tool's complexity: it covers input expectations, all output components, source attribution, behavioral constraints (Dog-only, educational), and conditional information. Given the existence of an output schema, the description does not need to detail return structure, but it does so anyway, adding value.

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 parameter 'disease' with type string and no description. The tool description clarifies that it accepts a 'canine inherited disease (name or OMIA id)', adding meaning. However, it does not specify format for OMIA ids (e.g., OMIA:######) or provide examples, which could improve precision. Given the single parameter and high coverage of its role, score 4.

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 defines the tool as mapping a canine inherited disease (name or OMIA id) to its OMIA clinical record, listing specific output components. It distinguishes itself from siblings like search_diseases by stating its exact scope and output, including the canonical sniff.world URL.

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

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

The description explicitly states when to use this tool: for a specific disease name or OMIA id. It also provides a clear alternative: 'For fuzzy candidates use search_diseases.' This gives the agent precise guidance on tool selection.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is dog-only, sources from OMIA (CC-BY), returns a canonical sniff.world URL, and lists output fields. It does not mention error handling or rate limits, but for a read-only lookup it is sufficiently transparent.

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

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

The description is concise (two sentences plus a note), front-loads the key purpose, and avoids redundancy. It could be slightly more structured (e.g., bullet points for output fields) but is clear and efficient.

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 (context signal true), the description fully explains the return fields: inheritance, causal genes, curated description, clinical signs, human OMIM analog + Mondo id, evidence base. It also specifies scope (dog-only) and data source, making the tool's context complete.

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

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

Schema coverage is 0% (no param descriptions in schema), so description must compensate. It explains that the 'query' parameter accepts a name or OMIA id, but does not provide format examples or distinguish how the tool interprets the input. This adds some meaning beyond the raw schema but could be more precise.

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 ('look up') and resource ('canine inherited disease by name or OMIA id'), and clearly distinguishes from siblings by mentioning when to use search_diseases and disease_links instead.

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 this tool is appropriate (looking up a specific disease) and when to use alternatives (search_diseases for disambiguation, disease_links for molecular links), providing clear usage boundaries.

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 provided, so description carries full burden. It does not disclose whether results are sorted descending, pagination limits, or any side effects. Only a vague functional statement.

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?

Single sentence is efficient and front-loaded with key information. However, it could be expanded slightly to improve clarity 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?

Despite having an output schema, the description lacks details about what 'top genes' means, how the atlas is defined, and whether results include metadata. Insufficient for confident tool selection.

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 has 0% description coverage, so description must compensate. But it makes no mention of the 'limit' parameter, leaving agents to infer its meaning from the schema alone.

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

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

Description clearly states the tool returns top genes by variant count, which is distinct from siblings like gene_summary. 'Discovery aid' adds context but could be more precise.

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. 'Discovery aid' hints at exploratory use but lacks detail on 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?

No annotations provided; description discloses pagination and a filter but fails to mention other behaviors like authorization needs, rate limits, or whether operations are read-only. Basic but incomplete.

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 efficient sentences, front-loaded with purpose and key details. 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?

Covers essential usage (pagination, filter) for a tool with output schema; but missing behavioral details and usage guidelines, leaving gaps for an 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?

Description explains limit default and af_min as global AF filter, but gene_symbol is not elaborated beyond 'by gene symbol' in purpose. Schema coverage 0% means description adds some value but not full.

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

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

Description clearly states it returns variants for a given gene symbol, ranked by impact and ESM2 damage, with pagination. Differentiates from siblings like variant_search which searches across variants.

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?

Implies usage for retrieving variants per gene; mentions af_min filter but gives no explicit when-to-use vs alternatives. No when-not or alternatives given.

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 lists metadata contents, omitting side effects, auth needs, 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?

Single sentence, front-loaded with purpose, lists specific items efficiently—every word 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?

Given zero parameters and an existing output schema, the description is adequate for a simple metadata retrieval tool; could mention return format but not necessary.

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?

No parameters exist; schema coverage is 100% trivially; baseline for 0 parameters is 4, and the description adds no parameter info beyond what's implied.

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 'Atlas metadata' and lists specific items (release, DOI, assembly, etc.), distinguishing it from sibling tools that handle specific queries like variant context or breed similarity.

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; no context about prerequisites or exclusions, leaving the agent to infer 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 are provided, so the description carries the full burden. It explains the computation (Euclidean distance in PCA-256 space) but omits behavioral aspects like side effects, authorization requirements, or performance characteristics. As a readonly computation tool, the description is adequate but not rich.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no fluff. Every word adds value.

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

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

Given that an output schema exists (context signal), the description does not need to explain return values. It sufficiently describes the tool's function, though it could be slightly more explicit about the 'k' parameter and the number of results.

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 mentions 'breed' and 'top-10' which correspond to the 'breed' parameter and default 'k' value, but does not explicitly describe the 'k' parameter or its range. The description adds context (genetic space) but does not fully explain 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 genetically nearest breeds using PCA-256 breed co-embedding, specifying 'top-10-PC Euclidean in canine genetic space'. This distinguishes it from sibling tools like 'breed_similarity' (which might use different similarity measures) and 'breeds_in_atlas'.

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

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

The description provides a clear use case ('answers what breeds are most genetically similar to X?') but does not explicitly state when not to use it or mention alternatives. The sibling tool 'breed_similarity' suggests a possible alternative, but no contrast 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?

No annotations provided, so description carries full burden. It specifies output format, search behavior, and species restriction, though missing details like pagination 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?

Two sentences, no fluff. First sentence covers purpose and output, second gives usage hint. Efficient but could be more 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?

For a search tool with output schema, description covers purpose, output, usage hint, and scope. Missing limit explanation but otherwise 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 descriptions are absent (0% coverage). Description explains query as free text and implies limit from default, but does not explicitly describe limit parameter.

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 searches a canine disease catalogue by free text, returns ranked candidates with fields, and distinguishes from disease_lookup.

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 says use before disease_lookup when exact name is unknown, and restricts to dog-only. Good guidance, though no explicit when-not 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?

No annotations are provided, so the description covers behavior well: it indicates the tool searches the whole knowledge base, returns ranked entities with snippets and dimension fields, and explains filter syntax. It does not mention any destructive behavior or auth requirements, which is acceptable for a read-only search.

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 dense paragraph that front-loads the purpose and provides examples. It contains no fluff, but could be slightly more structured (e.g., bullet points) for readability. 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 tool has 4 parameters with no schema descriptions, no annotations, and an output schema exists, the description explains the overall functionality and two parameter uses well. However, it does not detail the return format beyond a brief mention, and lacks coverage for query and top_k.

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%, and the description adds meaning for filters and entity_type with examples and facet list. However, query and top_k are not explained beyond what the schema provides (name and type). The description partially compensates for the lack of schema descriptions but not fully.

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

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

The description clearly states the tool performs 'Faceted hybrid + semantic-ranker search' over the entire knowledge base, listing example intents and distinguishing it from sibling tools like variant_search. It specifies the scope and type of 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?

The description explicitly says 'Use for fuzzy/thematic intent' with example queries. It explains how to use entity_type and filters with patterns. However, it does not explicitly state when to use alternative tools or provide a when-not-to-use section.

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 provided, so the description carries full burden. It lists return fields but does not disclose behaviors such as required permissions, rate limits, or error handling for invalid positions. As a lookup tool, it is likely read-only, but this is not stated.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and key outputs. No extraneous words, and the main action 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?

The tool is simple (one parameter, has output schema). The description covers the main return fields and purpose. However, it lacks usage guidance and error context, but overall sufficient for a straightforward lookup tool.

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

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

Schema description coverage is 0%, so the description must compensate. It specifies 'by CanFam4 position', giving genome assembly context, but does not detail the exact format expected (e.g., 'chr:pos' or 'ref/alt'). Partial guidance, but could be more precise.

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 is a single-variant lookup by CanFam4 position, listing specific outputs (ref/alt, AF, consequence, etc.). This distinguishes it from sibling tools like variant_search (which likely searches multiple variants) and ask_variant_context (which may provide broader context).

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. The description implies it is for a specific variant by genomic position, but does not mention scenarios where variant_search or ask_variant_context might be preferred.

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 provided, so the description carries full burden. It discloses return format (total_count + capped list max 200) and a nuanced note about popmax breed. However, it doesn't mention if the operation is read-only or any potential side effects, but 'discovery' implies read-only.

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

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

The description is concise with 3 sentences, front-loading the purpose. It uses a colon and list format for predicates, which is efficient. However, it could be slightly more structured with line breaks.

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 (9.67M variants, 7 optional parameters), the description covers key aspects: filter predicates, return format, and a special note. Output schema exists, so return values are handled. Missing details on sorting or pagination beyond the cap, but acceptable.

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 compensates well. It explains the meaning of esm_max, phylop_min, popmax_min, gene_in, consequence, and impact (with allowed values). Only 'limit' is not explained, which is common.

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 'Filtered discovery over all 9.67M variants' with specific verb and resource. It lists all filter predicates, differentiating it from sibling tools like variant_lookup.

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 states predicates can be combined freely but does not explicitly guide when to use this tool vs alternatives or when not to use it. It implies usage for filtering discovery, but no exclusions or sibling comparisons.

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