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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine value beyond that: the returned evidence categories (ACMG verdict with points/criteria, gnomAD frequency, REVEL/AlphaMissense/SpliceAI scores, ClinVar status, transcript consequences, citation links) plus the 'research use only; not a diagnosis' caveat. Minor gap: it doesn't state whether results are cached or how quickly they change, but the openWorld hint covers external data.

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 first sentence is front-loaded with the core action, and the routing hint follows immediately. The return-value enumeration is somewhat long, but since the output schema exists it is arguably redundant rather than wasteful, keeping this just below top marks.

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

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

With an output schema present, full annotation coverage, and a low-weight parameter surface, the description supplies everything an agent still needs: routing intent, a research-use disclaimer, and a summary of returned evidence. Nothing essential is missing for a correct call.

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

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

Schema description coverage is 100% and each parameter carries an example, so baseline is 3. The description adds nothing about input formats beyond what the schema already documents (variant encodings, genome builds, transcript override), so it neither compensates nor detracts.

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

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

The description opens with a specific verb+resource ('Annotate and classify one human genetic variant using GeneBe'), which unambiguously separates it from siblings like convert_variant or get_gene. An agent can determine the tool's function without inspecting the schema.

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

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

The explicit routing statement 'Start here for any question about a variant (what is it, is it pathogenic/benign, how common is it)' gives a clear when-to-use signal. However, no explicit exclusions or named alternatives (e.g., use convert_variant for coordinate transforms, liftover_coordinate for build changes) are provided, so the sibling differentiation is only implied.

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 readOnly, idempotent, non-destructive and open-world, so the score is judged on added context; the description adds that output is normalized to hg38 and that no classification is performed. It does not state behavior on unparseable or ambiguous input (parse failures, multiple mappings), which is the main residual unknown.

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, front-loaded with the verb and output, followed by usage scoping. Every clause carries information and nothing is repeated from structured fields verbatim.

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?

Output schema exists so return values need not be explained, annotations carry the safety profile, and both parameters are documented in the schema. The only material omission is guidance versus liftover_coordinate, which matters because both touch hg19/hg38 conversion.

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

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

Schema coverage is 100%, so the variant formats and the input_genome enum plus its hg19-to-hg38 lifting note are already documented in the schema. The description's phrase 'written in any notation' echoes the schema's format list rather than adding new semantics, so baseline 3 applies.

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

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

States a specific verb+resource ('Convert a variant ... into normalized hg38 genomic coordinates') and immediately sets itself apart from annotate_variant by clarifying it returns chr/pos/ref/alt without annotation.

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

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

Gives an explicit when-to-use ('when you only need the chr/pos/ref/alt') and an explicit when-not with a named alternative ('use annotate_variant for that'). It does not address the nearby sibling liftover_coordinate, which overlaps conceptually since hg19 input is lifted to hg38, leaving one confusable pair unresolved.

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

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

Annotations already cover read-only/idempotent/no-destruction, and the description adds genuinely new behavior: the output is an ASCII rendering of the decision tree, the default is the germline ACMG verdict, and two somatic trees can be requested. Minor gaps remain — no mention of what happens when a variant hasn't been annotated yet or is unresolvable — but this is well beyond annotation coverage.

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

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

Front-loaded with the purpose, then the trigger condition, then the return format and defaults — a sensible order with no filler. The tree enumeration is stated twice (once in prose, once implicitly via the schema defaults), a small redundancy but not harmful.

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

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

With an output schema present, the description needn't detail return values, yet it still characterizes the output shape (ASCII decision tree). Combined with the usage trigger and tree options, an agent has everything needed to invoke this correctly after annotate_variant.

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

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

Schema coverage is 100%, so baseline would be 3; the description adds the tree-to-version pairing ('germline' 2019, 'oncogenicity' 2022, 'acgs-uk-onco' 2025) and restates that variant accepts any notation annotate_variant takes. It does not resolve the edge case of passing tree='oncogenicity' while version defaults to '2019', which would be the one clarification that adds real 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?

States a specific verb and resource ('explain step by step why each classification criterion did or did not apply') and clearly distinguishes itself from sibling annotate_variant by being the post-hoc explanation layer rather than the annotator. An agent can tell instantly what this produces: an ASCII decision tree of evaluated conditions.

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

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

Explicit sequencing ('Use after annotate_variant when the user asks "why was this classified that way?"') names both the prerequisite tool and the triggering user intent. It also states the default tree and which non-default trees exist, so the agent knows when to deviate from the default.

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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations cannot carry: transcripts are capped and ordered MANE Select first, with total_transcripts as the escape hatch for truncation. It says nothing about auth or rate limits, keeping it short of a 5.

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

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

Two sentences, zero filler, with the purpose and distinguishing scope front-loaded before the transcript caveat. Nothing repeats the schema or annotations verbatim.

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

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

A two-parameter, fully documented read-only lookup with an output schema, so return shapes need no explanation. The only behavioral trap — silent transcript truncation — is disclosed, which is exactly what an agent needs to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by explaining what include_transcripts actually yields — a capped, MANE-first list with total_transcripts to detect truncation. That is semantics beyond the schema's bare 'Also list the gene's transcripts.'

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

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

States a specific verb and resource ('Look up a human gene') and enumerates the payload: identifiers, location, MANE Select transcript, ClinGen validity. It also explicitly separates itself from variant-oriented siblings with 'a gene rather than a specific variant.'

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

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

Gives a clear selection rule: use for gene-level questions, not variant-level ones, which implicitly routes to annotate_variant/get_variant_effects. It stops short of naming the specific sibling tool to pick instead, leaving the agent to map 'specific variant' onto 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. On top of that the description discloses return ordering (most severe and MANE Select transcripts first) and what it deliberately omits (frequencies, classification), which is genuine behavioral context beyond the 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?

Three short sentences: scope first, return contents second, limitations third. No filler, and the ordering guarantee is front-loaded where an agent will read it.

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

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

An output schema exists, so return values need not be spelled out, and the description still summarizes the key fields and ranking. Adequate for a read-only, two-parameter tool; only minor gaps remain around accepted variant notation (deferred to annotate_variant) and error 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?

Schema coverage is 100%, with both `genome` (enum, default hg38) and `variant` fully documented in the schema. The description adds nothing about parameters and never mentions the genome-build parameter, so the schema carries the full load — baseline 3.

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 gives a precise verb and resource: 'List a variant's predicted molecular consequences on every overlapping transcript,' with the per-transcript scope made explicit. It distinguishes itself from the heavier sibling annotate_variant by stating it covers all overlapping transcripts and is 'lightweight,' though no sibling is named directly.

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

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

'Lightweight: no frequencies or classification' supplies a clear negative scope that tells an agent when this tool is the right fit versus a fuller annotation call. It stops short of explicitly naming an alternative such as annotate_variant as the tool to use when frequencies are needed.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the RESOLVED/AMBIGUOUS/other status contract, the possibility of unmappable coordinates surfaced via errors, and that variant ref/alt are rebuilt against the target reference with warnings like REF_MISMATCH.

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

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

The purpose sentence is front-loaded and the second paragraph is dedicated to result interpretation, so every sentence earns its place. Slightly dense in the status sentence, but no filler.

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

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

With an output schema present, the description needn't enumerate return fields, and it correctly focuses on how to read status and warnings. The remaining gap is sibling disambiguation against `convert_variant`, which an agent would still have to resolve by opening both schemas.

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

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

Schema description coverage is 100% and each parameter carries its own description, so the schema does the heavy lifting. The description adds only marginal signal, reiterating the build names and noting variant handling, without extra format or edge-case detail for `query` beyond what the schema lists.

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

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

States a specific verb (convert) and resource (genomic position, interval or variant) plus the supported builds (hg19, hg38, t2t). It is clear on its own, but it never distinguishes itself from the sibling `convert_variant`, which plausibly overlaps for the variant case — the one ambiguity that matters most here.

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

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

Usage is only implied by the purpose statement; there is no explicit when-to-use/when-not and no routing to or away from `convert_variant` or `annotate_variant`. What guidance exists is about interpreting output (status values, errors), not about tool selection.

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