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

With no annotations, the description carries the full burden and does well: it discloses that inference runs live via score_variant with recommended scorers, that the result is tagged source: live, that it covers SNVs/indels/MNVs, and that outputs are research predictions with no pathogenic/benign call. It does not mention cost, rate limits, or latency for a 1-100 variant live call.

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 paragraphs, purpose and alternative front-loaded before the mechanism and disclaimer. Mostly efficient, though the SNV phrasing in the first paragraph and the modality coverage in the second overlap enough to introduce mild ambiguity rather than pure redundancy.

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

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

No output schema or annotations exist, so the description must supply behavioral context, and it covers the live-inference source flag, modality scope, and non-clinical disclaimer. It stops short of describing the shape of the ranking output or how many results are returned, which would fully complete it for a 1-100 variant tool.

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

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

Schema description coverage is 100%, so start/end/chromosome/variants are already well documented including the 1-100 bound. The description adds no additional semantics (e.g., interpretation of the locus label fields) beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (rank) and resource (variants of a locus) plus the ranking criterion (largest absolute quantile across modalities) and the goal (prioritize follow-up candidates). An agent can distinguish it from sibling scorers like predict_variant_effect or batch_score_variants from this alone.

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 routes SNV-only inputs to atlas_lookup_variants or atlas_scan_region, naming the condition (SNV-only) and the benefit (faster, adds AVI). However the phrasing 'For single-nucleotide variants only' sits awkwardly beside the later claim that the tool handles SNVs, indels and MNVs, leaving the exact when-not boundary slightly muddy.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that live inference runs via score_variant using SDK-recommended scorers, the variant types supported (SNV, indel, MNV), that the response carries `source: live`, and that it makes no pathogenic/benign call. This is rich behavioral context an agent cannot get from structured fields.

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, front-loaded paragraphs: what it predicts, how it runs, and the disclaimers. Efficient overall, though the final disclaimer paragraph is somewhat long and repeats the non-clinical framing already implied by the first paragraph.

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

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

With no output schema, the description usefully explains what the result contains (source marker, scores and calibrated quantiles) and what it deliberately omits (pathogenicity calls). It doesn't detail the per-modality result structure, but for an annotation tool with full schema coverage the coverage 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 100%, so each parameter (chromosome, position, ref, alt, tissue_type) is already documented in the schema with patterns and defaults. The description adds no syntax or semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (annotate/predict) and resource (variant effects across all regulatory modalities), enumerating the modalities covered: accessibility, histone marks, TF binding, CAGE, RNA-seq, splice sites, polyadenylation and contact maps. The phrase 'across every regulatory modality at once' implicitly differentiates it from single-modality siblings like predict_splice_impact or predict_tf_binding_impact.

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 frames the intended use ('research prioritization, not clinical classifications') and states it does not label the variant, which steers an agent away from it when a pathogenic/benign call is needed (assess_pathogenicity). It does not, however, name a specific sibling alternative or give explicit when-not conditions beyond the clinical boundary.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that `classification` is always null, that `avi_score` is null on the live path because only the Atlas serves it, exactly which source answers which variant class, that the chosen source is always echoed in the result, and the shape of the returned per-scorer data. It also sets a clear research-use boundary (no pathogenic/benign call).

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 front-loaded with the disambiguation and return shape, and each paragraph has a distinct job (naming, returns, source routing, caveat). It is slightly long and repeats the no-pathogenic-call point twice (once after the name caveat, again in the closing paragraph), which is minor redundancy rather than padding.

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 7-parameter tool with no annotations and no output schema, the description is largely sufficient: it explains the return contents (strongest effect per scorer, largest absolute quantile, AVI) and the source semantics. It stops short of a fully enumerated result structure and does not note any cost or latency difference for the live-inference path, which an agent weighing `source` would benefit from.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including `source`, `scorers`, and `tissue_type`. The description adds only marginal parameter meaning beyond that (the AVI-scorers-only-in-Atlas caveat, which is already in the schema), so the baseline of 3 is appropriate.

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 opening sentence gives a specific verb and resource ('predicted effect size of a variant across modalities') and the second immediately neutralizes the misleading tool name by stating it does NOT classify pathogenicity and that `classification` is always null. It also delineates the two answering paths (SNV via Atlas, indel/MNV via live inference), so an agent can tell what the tool will and won't produce without opening the schema.

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

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

It states the purpose context ('for prioritization') and explains the automatic source selection plus the `source` override, including what happens on fallback. It does not, however, name or exclude the very similar sibling `predict_variant_effect` or `predict_tissue_specific`, so the agent must infer routing between closely related tools.

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

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

With no annotations, the description carries full load and does well: it discloses the return contents (name, number of tracks, assays), a caching behavior ('Cached for the session after the first call'), and the data scope (hg38, chr1-22, chrX, chrY, SNVs only). It does not state permissions or pagination, but for a static enumerator that is minor.

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 action and return contents, then scope constraints. Three short paragraphs earn their place, though the long parenthetical scorer-name enumeration adds bulk that could be trimmed.

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

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

For a zero-param enumerator with no output schema, the description covers what is returned, how to use it downstream, caching, and the dataset boundaries. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description adds cross-tool value by explaining how the returned names feed the `scorers` parameter elsewhere, which is meaningful context 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?

States a specific verb and resource ('List the variant scorers available in the AlphaGenome Atlas') and enumerates the concrete scorer names returned. An agent can distinguish this enumeration tool from scoring tools like predict_variant_effect without opening any 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?

Explicitly routes usage: 'Use these names in the `scorers` parameter of the other tools,' and names the alternative and exclusion ('Indels and multi-nucleotide variants are not in it; use predict_variant_effect for those'). Both when-to-use and when-not-to-use are stated.

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, and it does a lot: read-only lookup semantics, no model call, second-scale latency, top_n default/max, a 40,000-character response cap, and explicit validation-error behavior when ref does not match hg38. It omits auth/permission requirements and any rate-limit note, which are the only remaining gaps.

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 what and how fast, then response shape, then scope limits, then caveats, then an example. Structure is good and most sentences earn their place, though the trailing example sentence adds little given the clear parameter docs.

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?

There is no output schema, so the description must explain returns, and it does: per-scorer ranked rows with quantile, gene, tissue/cell type, and assay, plus the summary-not-matrix cap. Combined with scope limits and error behavior, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: it names the default scorer set (AVI_SCORE plus one per modality) and lists the actual modalities, and reaffirms the top_n default/max. It goes beyond restating the schema.

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

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

States a specific verb (look up), resource (precomputed AlphaGenome scores), and scope (one single-nucleotide variant). It also distinguishes itself from the nearest functional sibling by explaining the Atlas is precomputed-only, so the agent can tell it apart without opening the schema.

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

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

Explicitly says indels and multi-nucleotide variants are not supported and routes those to predict_variant_effect, and implies fast use via 'no model call, answers in seconds'. It does not, however, address when to use this versus the near-identically named atlas_lookup_variants, which is a real ambiguity left to inference.

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

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

With no annotations, the description carries the full burden and does so richly: one row per variant, default AVI_SCORE, largest-absolute-quantile ranking with multiple scorers, missing/rejected variants listed separately with reasons rather than failing the call, the 40,000-character response cap, and a research-only (non-clinical) disclaimer. This is well beyond what the schema conveys.

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

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

Front-loaded with the core action and result shape, then scope limits, then caveats; each paragraph is purposeful. Slightly long, with the closing example and dual disclaimers bordering on extras, but nothing misleading or padded.

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?

No output schema exists, so the description must explain returns, and it does: ranked rows only, capped at top_n and 40,000 characters, with out-of-Atlas/rejected variants reported separately. An agent has everything needed to call and interpret it.

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 is 3, but the description adds real meaning: top_n defaults to 25 and caps at 100, and the choice of scorers changes the ranking method (largest absolute quantile). The only gap is that scoring syntax/format details remain in the schema.

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

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

States a specific verb (look up precomputed scores), resource (AlphaGenome SNV scores), and scope (up to 500 in one call, ranked). It distinguishes itself from siblings by noting indels/MNVs are out of scope and belong to predict_variant_effect, and the singular sibling atlas_lookup_variant is implicitly contrasted by the batch framing.

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

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

Names the alternative explicitly for the out-of-scope case ('Indels and multi-nucleotide variants are not in it; use predict_variant_effect for those') and points to atlas_list_scorers as the source of valid scorer names. Both when-to-use and when-not-to-use are covered.

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

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

With no annotations, the description carries the full burden and delivers: 10,000 bp cap (50,000 with allow_large_region), one API request per 32 bp under a requests-per-minute quota, minutes-long runtime, partial results marked "Incomplete" with the actually-scanned range, and scorer-dependent timings (AVI ~7 s vs DNASE 17 s vs CHIP_TF 86 s for 2,000 bp). It also caps and characterizes the response and disclaims clinical use.

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

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

Front-loads purpose, then layers limits, timing, scorer rules, and response shape, with an example at the end. Dense and mostly waste-free, though at roughly 280 words it is longer than strictly necessary and could merge the timing and quota sentences.

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?

No output schema exists, so the description carries the return contract itself: ranked rows only (never a full matrix), capped at top_n (default 25, max 100) and 40,000 characters, with "Incomplete" partials and their real range. Together with genome-build scope (hg38) and the research-only caveat, nothing needed to invoke or interpret the call is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning beyond it, notably that scorers must come from atlas_list_scorers, that AVI scorers are Atlas-only, and that allow_large_region trades speed for possible incompleteness. It does not add much on start/end/top_n beyond what the schema already spells out.

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

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

States a precise verb (scan) and resource (genomic region / all SNVs in an interval) and frames the question it answers ("which positions in this region matter most?" without running the model). It explicitly distinguishes itself from siblings atlas_lookup_variant and predict_variant_effect, so an agent can route without opening schemas.

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

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

Gives explicit when-to-use and when-not: indels/MNV must go to predict_variant_effect, and multi-row scorers like RNA_SEQ cannot be scanned — instead scan with AVI_SCORE and follow up with atlas_lookup_variant on top variants. Alternatives and the conditions selecting them are named directly.

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

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

With no annotations, the description carries the burden well: it discloses live inference execution, supported variant classes (SNV, indel, MNV), the output marker (source: live), and an explicit research-only / non-clinical limitation. It omits operational traits like latency, cost, or whether anything is persisted, which keeps 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?

Three short paragraphs, front-loaded with the core action and modality/scorer mapping, then execution detail, then the caveat. Every sentence contributes; only mild redundancy in the closing 'as returned' phrasing.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers what it computes and flags output provenance, but leaves the selection problem unsolved — an agent facing ~20 sibling scoring tools has no basis to choose this one. The core semantics are adequate; the comparative context is missing.

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

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

Schema coverage is only 50%, and the description compensates by mapping each modality enum value to concrete scorers (RNA_SEQ/CAGE, SPLICE_SITES, CHIP_TF, DNASE/ATAC) — meaning the schema does not carry. It also frames which variant types the variants array accepts, though it adds nothing about the positional/allele constraints already in the schema.

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

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

States a specific verb (rank) applied to a resource (variants) with an explicit scope (within one modality), and the modality-level framing plus scorer mapping is distinctive. However, it never names or distinguishes itself from near-identical siblings such as batch_score_variants, predict_variant_effect, or compare_variants, so the agent cannot tell from the description alone which to pick.

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 when-to-use, when-not-to-use, or alternative routing is given despite a very crowded sibling set of scoring/prediction tools. The only routing-like sentence ('score_variant with the SDK's recommended variant scorers') describes internal implementation rather than guiding tool selection.

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

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

With no annotations, the description carries the full burden and does real work: it explains that variants route per variant, results report per source, and groups from different sources are not comparable. It also discloses that no pathogenic/benign call is made and that scores/quantiles are returned as-is, though it does not cover error or failure 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?

Front-loaded with the key name-correction caveat, then threshold semantics, then the disclaimer and an example. Mostly efficient, though the 'not clinical classifications' disclaimer is restated twice ('no pathogenic/benign call is made'), which is slight redundancy.

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

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

With no output schema, the description does supply return context: results are ranked, reported per source, and scores and calibrated quantiles are returned as-is. Combined with the schema-documented source routing, an agent has enough to call and interpret the tool, though pagination/volume of returns is not addressed.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds genuine meaning to `threshold` beyond the schema: the smallest absolute calibrated quantile for Atlas-answered variants versus the largest quantile across modalities for live inference. That source-dependent semantics is not available 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?

States a specific action and resource: it keeps variants whose predicted effect reaches a threshold, ranked. It explicitly corrects its misleading name ('filters on predicted effect size, NOT on pathogenicity, and classifies nothing'), which is exactly the disambiguation an agent needs against siblings like assess_pathogenicity.

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 makes the use context clear (effect-size prioritization, not clinical classification) and gives a concrete triggering question as an example. It stops short of naming an alternative tool for the pathogenicity-classification use case it rules out, leaving that route implicit.

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 discloses key non-obvious behaviors: per-variant routing, two non-comparable ranked groups (AVI vs live), fallback counts in the result, and that outputs are predictions not clinical classifications. It does not cover rate limits, permissions, or error behavior for atlas-only mode.

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

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

Front-loaded with purpose followed by routing rules, metric mapping, and a disclaimer. Four paragraphs are justified by the genuinely complex behavior, though the example at the end is somewhat redundant given the clear opening sentence.

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 5-param tool with no output schema and no annotations, the description covers routing, grouping semantics, metric defaults, and the research-use limitation. Missing pieces are minor: no explanation of output fields beyond source counts, and no explicit prerequisite guidance.

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

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

Schema description coverage is 100%, so the schema already documents each parameter, and the description's metric mapping (rna_seq → RNA_SEQ, etc.) largely restates the enum. The description adds marginal value by clarifying that scorers come from atlas_list_scorers and that AVI scorers are Atlas-only, but this is mostly schema-adjacent rather than new 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 states a specific verb+resource+scope: 'Score up to 100 variants and rank them by predicted effect.' The batch nature and the 100-variant cap distinguish it from single-variant siblings, and the routing detail (Atlas vs live inference) further differentiates it.

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 explains internal routing behavior and the two-group result, but does not state when to use this over sibling batch tools like batch_pathogenicity_filter or batch_modality_screen, nor when a user should prefer single-variant predict_variant_effect. Usage is implied by the batch scope rather than explicitly guided.

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 and does substantial work: it discloses that inference is live, that the result carries 'source: live', and that outputs are model predictions for research prioritization rather than pathogenic/benign calls. It omits auth requirements, cost/latency expectations for live scoring, and rate limits, which keeps it from 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?

Front-loaded with the core operation in the first sentence, followed by scope, execution mode, and a necessary caveat. Every sentence earns its place, though the caveat paragraph is slightly verbose for the amount of information conveyed.

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?

No output schema exists, so the description must convey the return shape, and it does: one ranking per tissue, live source marker, and calibrated quantiles as returned. The only meaningful gap is the absence of any note on response size or runtime for up to 100 variants across 10 tissues in a live-inference 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% with only two top-level parameters, so the schema already documents tissues, variants, and every nested allele field. The description adds the implicit pairing semantics (each variant ranked in each tissue) but no formats or constraints beyond the schema. Baseline 3 applies.

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

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

States a specific verb and output shape: 'Rank several variants by predicted effect within each of several tissues: one ranking per tissue.' The variants-by-tissues matrix framing clearly distinguishes it from flat siblings like batch_score_variants or compare_variants. It does not name a sibling explicitly, so it stops short of a 5.

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

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

It gives input-eligibility guidance ('works for single-nucleotide variants, indels and multi-nucleotide variants'), which is useful, but never says when to choose this over batch_score_variants, predict_tissue_specific, or compare_variants. Usage is implied by the matrix output rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses that inference is live (and that results carry `source: live`), that outputs are model predictions for research prioritization, and that no pathogenic/benign call is made. It stops short of stating latency, cost, or whether repeated calls are deterministic, which would be valuable for a live-inference tool.

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

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

Front-loads the core action in the first sentence, then separates mechanics from the clinical-use caveat. Every sentence carries information; the only minor cost is the parenthetical about score_variant, which reads more like implementation detail than agent-facing 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?

With no output schema and no annotations, the description covers the essentials an agent needs: what is ranked, that inference is live, the supported variant classes, and the interpretation limits. Missing only operational details (runtime, determinism, error behavior) that would complete the picture for a live-inference 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%, so chromosome, position, ref, and alts are already documented, including patterns and the 1-20 alt limit. The description adds only implicit semantics (that indels/MNVs are expressed through ref/alts), so the baseline of 3 is appropriate.

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 ('Rank the alternate alleles of one position by predicted effect'), which makes the operation clear. It does not explicitly differentiate itself from close siblings like compare_variants or compare_variants_same_gene, so an agent must infer the boundary from the names alone.

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 useful scope guidance by naming the variant classes it handles ('single-nucleotide variants, indels and multi-nucleotide variants') and clarifies that inference is live. However, it never says when to prefer this tool over predict_variant_effect, compare_variants, or batch_score_variants, which is the main routing question for an agent.

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

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

With no annotations, the description carries the full burden and does well: it discloses that it runs live inference via score_variant with the SDK's recommended scorers, that the result carries `source: live`, that it accepts SNVs, indels and MNVs, and that outputs are AlphaGenome model predictions with no pathogenic/benign call. It does not cover cost, latency, or rate limits of live inference.

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 paragraphs, front-loaded with what the tool does and its key caveat, with no filler. The live-inference note and the research-use disclaimer each occupy one tight sentence.

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 two-nested-parameter tool with no annotations and no output schema, the description covers behaviour (live inference, source marker), accepted variant types, and the interpretive limits of the output. An agent has enough to call it correctly, though a hint about which sibling to prefer would close the remaining gap.

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 visible schema documents each nested field (chromosome, position, ref, alt, variant_id), and the description adds semantics the schema cannot: the protective_variant/risk_variant labels are supplied by the caller and are not validated or judged by the tool. That meaningfully guides how the two required objects should be assigned.

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

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

States a specific verb and resource: it compares two caller-labelled variants and reports predicted effect sizes per modality, and explicitly clarifies it does not assign protective/risk direction. This is clear, though it never names or contrasts with close siblings such as compare_variants, compare_alleles, or compare_variants_same_gene.

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

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

The description gives one implicit when-not: it does not judge which allele is protective or a risk, which tells the agent not to use it for classification. However, with 20+ siblings including several near-identical comparison tools, no alternative is named and no condition for selecting this over them is 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 carries the full burden and largely does: it discloses that this performs live inference via score_variant with the SDK's recommended scorers, that results carry `source: live`, and that outputs are model predictions for research prioritization with no pathogenic/benign call. That is meaningful behavioral context beyond a bare 'compare' statement, though it doesn't quantify latency/cost of live inference.

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

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

The core comparison semantics are front-loaded in the first sentence, followed by execution model, applicability, provenance, and a caveat. The 'comparison of predicted effect sizes, not of severity' idea is restated near the end, which is mildly redundant but not wasteful enough to hurt much.

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 two-nested-object tool with no output schema and no annotations, the description covers execution model, accepted variant types, provenance flag, and interpretive limits. It could say more about what the returned per-scorer structure looks like, but the essentials an agent needs to invoke it correctly are present.

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

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

The description adds no field-level meaning for variant1/variant2 beyond noting the accepted variant classes (SNV, indel, MNV) and an example using rsIDs. The nested schema properties do carry descriptions, so variant structure is largely covered there, making 3 the appropriate baseline.

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

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

The description names a concrete operation on a specific resource: pairwise comparison of two variants, reporting per-modality predicted effects and which has the larger absolute quantile per scorer. It even disambiguates the semantics ('comparison of predicted effect sizes, not of severity'). It stops short of explicitly routing against near-name siblings like compare_variants_same_gene or compare_alleles.

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 states the operating context (runs live inference, works for SNVs/indels/MNVs) and gives a worked example, which implies when it applies. However, there is no explicit when-not guidance or pointer to alternatives such as batch_score_variants for many variants or compare_variants_same_gene for the same-gene case, leaving sibling selection to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses that inference is live, which variant types are supported (SNV, indel, MNV), that output carries source: live, and that results are research-grade model predictions with no clinical call. It omits operational traits like latency, rate limits, or auth requirements.

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 compact sentences, front-loaded with the core action before the gene-name behavior and the output/disclaimer detail. Every sentence contributes; the structure is clean and easy to scan.

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

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

Since there is no output schema, the description usefully covers return semantics (ranking by predicted effect, source marker, calibrated quantiles reported as returned) and covers behavior in the absence of annotations. It could say more about the exact shape/ordering of the ranking result, but nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining that gene_name restricts the gene-level scorers (RNA_SEQ, SPLICE_SITES) to that gene, which the schema field ('Optional: gene symbol') does not convey.

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 specific verb+resource ('Rank several variants by their predicted effect on one gene') and adds technical scope (gene-level scorers RNA_SEQ, SPLICE_SITES). It does not explicitly name or distinguish itself from close siblings like compare_variants or compare_alleles, so an agent still has to infer the boundary.

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: the tool is scoped to ranking several variants within a single gene, and the gene_name clause hints at when the gene restriction applies. There is no explicit when-to-use, when-not-to-use, or routing to any of the many comparator siblings.

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

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

With no annotations, the description carries the full disclosure burden and largely succeeds: it explains the auto/atlas/live dispatch, that atlas errors instead of falling back, that live always runs inference, that the source is always reported, and that no pathogenicity call is made and results are research-only. It does not cover latency, rate limits, or failure modes of live inference, but the safety/dispatch profile is well documented.

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 text is front-loaded (output shape first, then source routing, then disclaimers, then an example) and each paragraph earns its place. It is somewhat verbose and repeats the source-selection semantics that the schema already states, which is the only real redundancy.

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

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

There is no output schema, so the description correctly carries the return-value burden by describing what the sentences contain and that the answering source is always stated. Combined with the parameter docs, an agent has enough to call and interpret the tool; only inter-tool routing against its many siblings remains unaddressed.

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

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

Schema coverage is 100%, so all seven parameters are already documented, including the source enum and the note that scorer names come from atlas_list_scorers. The description restates the source behavior but adds no format, syntax, or defaulting detail beyond what the schema provides, so the baseline 3 applies.

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

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

The opening states a concrete verb and resource: it produces plain sentences restating a variant's predicted effects, and spells out exactly what those sentences contain (AVI score, biggest contributions, per-modality strongest effect with direction). It also carves out a distinct niche ('descriptive only... no statement about pathogenicity'), which separates it from assess_pathogenicity and related siblings. However, it never distinguishes itself by name from the many predict_* siblings that also report variant effects.

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 rather than stated. The description explains how the source is chosen and that it can be overridden, and gives an example prompt, but it never says when an agent should pick this narration tool over predict_variant_effect, generate_variant_report, or assess_pathogenicity. No explicit when-not guidance is offered.

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

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

With no annotations, the description carries the full burden and does so: it discloses that the response is a capped summary (top_n default 25, max 100; 40,000-character ceiling), that the answering source is always reported, that atlas-only mode errors rather than falls back, and that no pathogenic/benign call is made. These are exactly the traits an agent needs before invoking.

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 what the tool produces, then source behavior, caps, and the research-use caveat, ending with a concrete example. It is somewhat long and the 'research summary, not a clinical report' disclaimer is stated twice, which is mild redundancy.

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

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

For a 7-parameter tool with no annotations and no output schema, the description covers the return shape (ranked rows, feature attributions, caps) and the safety framing well. The only gap is the dangling reference to a `top_n` control the caller cannot actually set via the schema, which could mislead about tuning result size.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining the source-routing semantics and that AVI scorers are Atlas-only, which reinforces the `scorers` and `source` fields. It is docked slightly because it discusses a `top_n` parameter (default 25, max 100) that does not exist in the input schema.

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

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

States a specific verb and resource (a fuller per-scorer report of one variant's predicted molecular effects) and explicitly positions it against predict_variant_effect ('more rows per scorer') and against clinical-report siblings ('no pathogenicity classification'). An agent can distinguish it from the 20+ siblings without opening a 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?

Explains the automatic Atlas-vs-live routing (SNV from precomputed Atlas, indels/MNV via live inference), when the fallback occurs, and that `source` overrides it — which is real selection guidance. It stops short of an explicit 'use this instead of predict_variant_effect when you need per-scorer breadth' rule, leaving the router to infer it from the comparison.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: it runs live model inference, declares output provenance (source: live), and disclaims clinical use. But it omits cost/latency implications of live inference, whether it is read-only/side-effect free, and any rate or permission 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 content is relevant but the opening sentence is awkwardly constructed and jargon-dense, requiring re-reading to parse the alt-vs-ref framing. Three short paragraphs are reasonably front-loaded with purpose, but the structure could be tighter and the scorer explanation clearer.

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

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

With no output schema, the description does explain what the two scorer outputs represent (log fold change vs expression level) and the live-inference provenance, which covers most of what an agent needs. The main remaining gap is the absence of any sibling differentiation for a crowded name-space.

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

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

Schema description coverage is 100%, so the schema already documents chromosome, position, ref, alt, and tissue_type in detail (including format, 1-based hg38, and CURIE examples). The description only implicitly touches tissue filtering via 'per gene and tissue,' adding little beyond the schema, so the baseline 3 applies.

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

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

The description states a specific operation: predicting expression for the alternate allele against the reference, naming the concrete scorers (RNA_SEQ for log fold change, RNA_SEQ_ACTIVE for expression level). It is clear on the resource and output semantics, but it never distinguishes itself from sibling tools like predict_expression_impact, compare_alleles, or predict_variant_effect that sound highly overlapping.

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

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

It gives some context: live inference, applicability to SNVs, indels and MNVs, and that results carry source: live. However, there is no explicit guidance on when to choose this over the many sibling prediction tools (e.g., predict_expression_impact or compare_alleles), leaving the choice to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that inference is live (score_variant with SDK-recommended scorers), that output is tagged source: live, and that results are raw model scores/quantiles with no pathogenic/benign call. It does not mention cost, latency, or failure modes of live inference, so it stops short of 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?

Three sentences with no filler; the modality and live-inference facts are front-loaded and the research-use caveat closes the description. Slightly dense but 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?

For a 5-param prediction tool with no output schema and no annotations, the description does explain what the return carries (live scores and calibrated quantiles, source tag) and sets expectations about research vs clinical use. Missing only operational details like runtime/cost and whether tissue filtering changes output shape.

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

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

Schema description coverage is 100%, so the required allele, position and chromosome parameters are fully documented by the schema; the description adds no syntax or format detail. The optional tissue_type default behavior is only covered in the schema, not the description. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb+resource (predicted chromatin accessibility effects of a variant) and names the assay modalities (ATAC-seq and DNase-seq), which cleanly distinguishes it from sibling modality tools like predict_expression_impact, predict_splice_impact and predict_tf_binding_impact. An agent can select it without opening a 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?

Variant classes supported (SNV, indel, MNV) and the fact that it runs live inference are stated, which implies when it applies, but there is no explicit when-to-use/ when-not guidance nor a named alternative among the many sibling predictors. Usage must be inferred from the modality name.

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

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

With no annotations, the description carries the full burden and does fairly well: it discloses that inference is live (via score_variant with SDK-recommended scorers), that the response is marked `source: live`, and that no pathogenic/benign call is made. Missing are cost/latency implications of live inference and any failure-mode notes, 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?

The output scope is front-loaded in the first line, followed by computational behavior and the research-use disclaimer. It is tight for the number of concepts covered, though the disclaimer sentence is somewhat 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?

With no output schema, the description does describe the return content (per-gene/tissue log fold change, CAGE, calibrated quantiles, source marker), and with no annotations it covers the research-only caveat. It is largely complete for a prediction tool, though the absence of return-shape or failure detail is a minor gap.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, making 3 the baseline. The description's mention of 'per gene and tissue' loosely reinforces the tissue_type filter but adds no syntax or format detail beyond what the schema provides.

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

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

The description names a specific verb and resource ('predicted gene expression effects of a variant') and pins the output modalities (RNA-seq log fold change per gene/tissue, CAGE), which lets an agent distinguish it from modality-specific siblings like predict_splice_impact or predict_tf_binding_impact. It does not explicitly contrast itself with the near-neighbor predict_variant_effect, 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?

It states the applicable variant classes (SNV, indel, MNV) and that it runs live inference, which is useful scoping. But it offers no when-to-use/when-not guidance relative to alternatives such as predict_tissue_specific or assess_pathogenicity, so routing 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?

With no annotations, the description carries the full burden and does well: it discloses that inference runs live via score_variant, marks the result with source: live, defines the accepted variant classes, and warns that outputs are model predictions with no pathogenic/benign call. It omits runtime cost or failure modes, which keeps 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?

Three short blocks, led by the output scope, then the inference behavior, then the caveat — front-loaded and each sentence earns its place. Slightly redundant restatement of the non-clinical caveat keeps it from a 5.

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?

There is no output schema, but the description compensates by enumerating the returned elements (splice sites, usage, junctions, gene and junction per result) and flagging source: live. An agent has enough to invoke it correctly, though the shape of returned scores/quantiles is only sketched.

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

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

Schema description coverage is 100%, so position, ref, alt, chromosome, and tissue_type are fully documented in the schema already. The description adds no syntax or format guidance beyond that, so a baseline 3 is appropriate.

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-effect and resource: predicted splicing effects of a variant, enumerating the outputs (splice sites, splice site usage, splice junctions). It is clearly distinguishable from generic siblings like predict_variant_effect or predict_tf_binding_impact without opening a 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?

It gives clear scope (single-nucleotide variants, indels, multi-nucleotide variants) and implies the intended use case of research prioritization rather than clinical classification, which implicitly routes away from assess_pathogenicity. However, it never explicitly names when to prefer a sibling such as predict_variant_effect for a broader effect profile.

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

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

With no annotations, the description carries the full burden and does well: it discloses that inference is live (score_variant with recommended scorers), that the response carries `source: live`, and that results are model predictions with scores and calibrated quantiles and no pathogenic/benign call. It omits cost/latency or permission requirements, 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?

Three compact sentences, front-loaded with what the tool predicts before the mechanics and the disclaimer. Every sentence earns its place, though the boundary/limitation sentence is somewhat dense.

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

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

With no output schema and no annotations, the description usefully fills the gap: it names the returned contents (factor and cell type per track), the `source: live` marker, and the non-clinical nature of the scores. A 5 would require more on usage routing or failure/edge-case 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 description coverage is 100%, so chromosome, position, ref, alt and tissue_type are already fully documented in the schema. The description adds nothing parameter-specific (e.g., no note on tissue_type filtering behavior beyond the schema's own text), so the baseline of 3 applies.

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

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

The description states a specific verb+resource: predicted transcription factor binding effects of a variant, scoped to TF ChIP-seq. This modality specificity distinguishes it from siblings like predict_chromatin_impact or predict_splice_impact, though it never names a sibling explicitly to reinforce the contrast.

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?

There is no explicit when-to-use statement, no condition for choosing this over the other predict_* siblings, and no exclusions. Variant-type support is mentioned ('single-nucleotide variants, indels and multi-nucleotide variants') but that is a capability, not usage guidance.

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

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

With no annotations provided, the description carries the burden well: it discloses that inference runs live (latency/cost implication), that results carry `source: live`, what is returned (scores and calibrated quantiles), and that no pathogenic/benign call is made. It omits auth/permission and rate-limit details, but otherwise adds meaningful behavioral context.

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

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

Three short blocks with the core purpose front-loaded and no filler paragraphs; the live-inference and research-use notes each earn their place. The opening sentence 'the same scores' lacks an antecedent, which briefly obscures what it is being compared against.

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?

No output schema exists, and the description compensates by describing the return content (scores, calibrated quantiles, `source: live`) plus the research-only scope, and it covers supported variant classes. It is complete enough to call correctly, with only routing to sibling tools left implicit.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds modest meaning by mapping a tissue entry to 'the tracks of one tissue at a time', but it gives no extra detail on the chromosome/position/ref/alt inputs beyond what the schema already documents.

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

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

States a specific verb+resource ('predicted effect of a variant in each of several tissues') and clarifies the output shape (same scores filtered to one tissue's tracks at a time). It is distinguishable from siblings like batch_tissue_comparison and predict_variant_effect, though it never explicitly names which sibling it is not.

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 via the example ('Compare the predicted effect of chr19:44908684 T>C in brain, liver and heart'). There is no explicit statement of when to prefer this over predict_variant_effect, compare_variants, or batch_tissue_comparison, so the agent must infer routing.

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

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

With no annotations, the description carries the full burden and delivers: it discloses auto/live/atlas source selection and fallback, that the result states which source answered, that output is a capped summary rather than a full matrix, and that results are model predictions not clinical calls. A minor issue is that it describes a `top_n` cap (default 25, max 100) that does not appear in the input schema, which could mislead.

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

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

Front-loaded with the core purpose and then organized into scope, source behavior, response shape, and a caveat, which is efficient paragraphing. It runs a little long and includes the unreconciled `top_n` detail, but every section largely 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?

For an 8-parameter, no-annotation, no-output-schema tool, the description covers the response shape (ranked rows, per-modality strongest tracks, character cap), source dispatch, and the research-only caveat. What is missing is explicit sibling differentiation and reconciliation of the `top_n` cap with the actual schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces source semantics and notes that scorer names come from atlas_list_scorers and that AVI scorers are Atlas-only, but most parameter meaning is already carried by the rich schema, and the phantom `top_n` is never reconciled.

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 (predicted regulatory effect) and resource (genetic variant) and enumerates the modalities returned (expression, TSS, chromatin, histone, TF binding, splicing) plus the AVI score. It is clear what the tool produces, but it never explicitly contrasts itself with narrower siblings like predict_splice_impact or predict_tissue_specific, so an agent must infer the boundary.

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 explains the automatic source selection and the override via `source`, plus fallback behavior, which is useful invocation guidance, and it gives a concrete example query. However, it offers no when-to-use/when-not guidance relative to the ~20 sibling prediction tools, leaving alternative selection to inference.

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