workbench

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

Annotations already declare readOnlyHint and idempotentHint. The description adds details about return values (confidence, model version, file URLs) and the failure case ({found:false}), plus the license. No contradictions.

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

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

Two sentences, front-loaded with the core action, no redundancy.

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

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

Given the simple one-parameter input and no output schema, the description fully explains the return format including success and failure cases.

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

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

Schema coverage is 100% with a clear description and example. The tool description does not add further parameter guidance beyond the schema.

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

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

The description specifies the action ('look up'), the resource ('UniProt accession in the AlphaFold Protein Structure Database'), and the database license. It clearly distinguishes itself from sibling tools like 'protein_annotate' or 'sequence_fetch' by focusing solely on AlphaFold predictions.

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

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

The description implies use when needing AlphaFold predictions for a given UniProt accession. It does not explicitly state when not to use, but the narrow scope makes misapplication unlikely.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds rich behavioral context: it scans candidate sites, builds the antisense oligo with specific chemistry, screens for liabilities, and explicitly states what it does not do. This fully informs the agent of the tool's behavior.

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

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

The description is two sentences long, front-loads the core purpose, and includes all essential details without unnecessary words. Every sentence adds value.

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

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

While the purpose and behavior are well described, the output format is not mentioned. With no output schema to rely on, the agent is left uncertain about what the tool returns (e.g., list of designs, scores). This gap reduces completeness for a read-only design 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?

The input schema covers all three parameters with descriptions, but the description adds meaningful context by explaining the 5-10-5 architecture linking wing and length, and the screening steps. This provides additional semantics beyond the schema defaults and descriptions.

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

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

The description clearly states the tool designs ASO gapmers against mRNA targets, specifies the 5-10-5 architecture, and distinguishes itself from sibling tools like siRNA or CRISPR design tools by focusing on antisense oligonucleotides and explicitly mentioning no transcriptome-wide off-target search.

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

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

The description gives clear context for when to use this tool (for ASO gapmer design) and mentions a key limitation (no transcriptome-wide off-target search), implying alternative tools might be needed for that. However, it does not explicitly name alternatives or state when not to use it.

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 annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds genuinely valuable behavioral context: outcomes are 'ranked by how few independent mis-ligations each needs,' cross-talk data is explicitly attributed (Potapov/Pryor ligation data), and the limitation is honestly disclosed ('Reports no probability per outcome: the ligation data does not measure transformation or vector background'). This is exactly the kind of caveat-dense behavioral disclosure the annotations can't express.

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 opening sentence is information-dense and slightly run-on (though it earns its length by cataloguing failure modes), and the middle sentences are efficient. It's front-loaded with the core purpose and ends with an honest limitation. Minor wordiness like 'the backbone self-circularised' adds color but is justifiable for a molecular biology audience. No waste, but a touch over-long.

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

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

Given the complexity — 8 parameters, no output schema, two assembly methods, two datasets, and a nuanced cross-talk annotation system — the description is remarkably complete. It explains the ranking principle, data provenance, method-specific behavior, downstream tool integration, and important limitations. The lack of an output schema raises the burden on this description to characterize return behavior (ranked full sequences), which it does well.

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 rich detail: enums for method and dataset, defaults documented, cross-tool references ('the same list cloning_simulate takes'), and contextual flags like 'Golden Gate only' and 'Gibson only.' The description adds no parameter-specific semantics not already in the schema, so the baseline of 3 for high-coverage schemas 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 description pairs a specific verb ('Enumerate') with a precisely-scoped resource ('the specific wrong plasmids a multi-part Golden Gate or Gibson assembly can produce') and catalogs what that entails (dropped, inverted, duplicated, swapped parts; backbone self-circularised). It clearly differentiates from siblings like cloning_simulate (generates intended assemblies) and verify_assembly, while the output direction toward diagnostic_digest disambiguates it from that tool.

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 clear workflow guidance ('Feed the result to diagnostic_digest to pick a screening enzyme') and realistic exclusions ('Reports no probability per outcome'), implying when the tool is insufficient. However, it never explicitly names the obvious sibling alternative (cloning_simulate) for the 'intended assembly' case — it says 'the same list cloning_simulate takes' but doesn't say 'if you want the correct plasmid, use X instead.' A named alternative would push this to 5.

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

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

The description explicitly states what the tool does not do ('Reports no yield and assigns no share of the band') and explains its ranking logic based on 3' end matching. It also discloses failure behavior ('Says plainly when nothing on this template explains the size'). Annotations include readOnlyHint and idempotentHint, and the description aligns with these without contradiction.

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

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

The description is appropriately sized—three sentences that front-load the purpose, then detail algorithm and expectations. Every sentence adds value, with no filler or repetition of schema details.

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

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

Given the tool's complexity (algorithmic enumeration, ranking, and failure modes), the description covers what the tool does, what it doesn't do, and what it returns. There is no output schema, but the description sufficiently sets expectations for outputs and edge cases.

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

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

The input schema already provides 100% description coverage for all 9 parameters. The description adds no extra meaning about individual parameters beyond restating that the tool uses template, primers, and observed size. It doesn't clarify format, units, or relationships beyond what the schema says, so it meets the baseline but doesn't exceed it.

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

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

The description clearly states the tool's purpose: to explain a band on a gel by enumerating priming-site pairs and ranking them. It uses a specific verb+resource ('Explain a band you measured') and distinguishes itself from siblings like in_silico_pcr by focusing on explaining observed bands rather than predicting them.

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 clear context (use when you have a measured band and want its origin) but does not explicitly name alternatives or state when not to use it. It does imply that it's for troubleshooting unexpected bands, but lacks direct comparisons to related tools like primer_specificity.

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

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

The description adds behavioral details beyond annotations (readOnlyHint=true): it explains strand handling, reporting of forward-strand changes for reverse guides, and classification of edits. Annotations already indicate safety, so the additional context is valuable. It lacks details on output format or pagination but is sufficient.

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

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

The description is a single paragraph that is front-loaded with the main purpose and contains no fluff. It is slightly long but every sentence adds value. It could be slightly more structured (e.g., bullet points) but remains clear and efficient.

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

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

Given no output schema, the description fully explains what the tool returns: reported editable bases, bystander flags, amino-acid consequences, and ranking of bystander-free guides. It covers strands and editing types completely. No gaps 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?

With 100% schema coverage, the description still adds significant meaning: explaining what edible bases are, what bystander edits mean, and how frameStart affects amino-acid classification. This goes beyond the schema descriptions, providing critical context for proper parameter usage.

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

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

The description clearly states the tool designs cytosine (CBE, C→T) or adenine (ABE, A→G) base-editing gRNAs for SpCas9 targets, reports editable bases, flags bystander edits, and classifies amino-acid consequences. It distinguishes itself from sibling tools like crispr_grna_design and prime_editing_design by specifying the base editing context.

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

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

The description implies usage for base editing design and differentiates from siblings by naming specific editors (CBE, ABE). However, it does not explicitly state when not to use this tool or provide alternatives, leaving some inference to the agent.

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

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

Annotations only declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context: 'PREDICTED, NOT MEASURED', no published validation, directional one-sided bias, non-constant variance, the noise floor semantics, and pool-level interpretation. No contradiction with annotations.

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

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

The description is extremely long and repetitive, covering the same caveats multiple times ('reported but not quantified', crosstalk background, indel blindness, validation status). Important information is buried in dense prose rather than structured with bullets or section headers, making it harder for an agent to extract actionable guidance.

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

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

Despite lacking an output schema, the description thoroughly explains return values: per-position percentages, z-scores, target/bystanders, background distribution, robust sd, outlier counts, and noiseFloorPercent with null semantics. It also covers coordinate conventions, failure conditions, and the excludedReason behavior, making it complete for a complex 14-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds further meaning beyond the schema: it explains that targetPosition prevents bystander relabeling, that offset reports identity at the offset used, that raising zThreshold raises the noise floor, and the explicit-window from/to semantics on the control strand.

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: 'Quantify CBE/ABE base editing from a pair of Sanger traces'. It distinguishes itself from indels ('Blind to indels') and NGS-free quantification, differentiating it from sibling tools like sanger_indel_spectrum and sanger_knockin_quant.

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 specifies when the tool is valid ('substitution', 'unedited control that starts within ±40 bases') and when it is not ('Not valid for indels', 'Not valid where the control read already carries the alt base'). It also describes the two window-location modes (editor id + protospacer, or explicit arguments), giving clear selection criteria.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to reiterate safety. It adds context about batch execution and return format but lacks details on error handling or limits. With annotations, this is adequate.

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

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

The description is two sentences, front-loaded with core action, and every sentence adds value. No wasted words.

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

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

Despite no output schema, the description mentions return format ('a table of per-record results'). Combined with annotations and schema, this is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema labels by explaining 'input' as multi-FASTA or one per line, 'tool' as any batchable tool name, and 'args' as shared arguments. This helps the agent understand parameter semantics.

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

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

The description clearly states the verb 'run' and the resource 'one SeqBench tool over many records at once'. It distinguishes from sibling tools, which are individual sequence analysis tools, making this a meta-tool for batching.

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

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

The description implies usage for applying a tool to multiple sequences, but does not explicitly state when not to use it or mention alternatives. However, given the context and sibling tools, the purpose is clear enough for an agent to decide.

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

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context by listing the types of analyses performed (composition, ORFs, enzymes, etc.), which helps the agent understand the scope. No contradictions with annotations.

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

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

The description is a single, concise sentence that front-loads the key purpose and lists the outputs efficiently. No unnecessary words.

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

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

Given the tool's complexity (multiple analysis types), the description covers the main outputs. However, it does not mention the output format or any caveats (e.g., optional parameters). Annotations and schema cover safety and parameter details, so overall completeness is good but not perfect.

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 parameter meanings are well-documented in the schema. The description adds no additional parameter semantics beyond what is in the schema, so baseline score 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 description clearly states that the tool auto-detects sequence type and provides a comprehensive characterization including composition, ORFs, enzymes, primers, protein properties, and a BLAST link. This effectively differentiates it from siblings that focus on specific aspects like find_orfs or protein_properties.

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

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

The description implies the tool is for comprehensive analysis ('One-paste tell me everything'), but does not explicitly state when to use it versus alternatives or when not to use it. Sibling tools provide context, but the description lacks direct 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?

The description adds substantial behavior beyond the annotations: it discloses that ordering is by evidence, not likelihood; that no probability is computed; that eliminated causes are reported with the eliminating observation; that design-impossible causes are omitted; and that inputs are rejected rather than skipped. All of this is consistent with readOnlyHint=true, openWorldHint=false, and idempotentHint=true — no contradiction.

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

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

The description is long, but the tool has 27 parameters and no output schema, so the density is largely justified; every sentence carries behavioral or output-format content. It is front-loaded with purpose, and the only mild redundancy is the input enumeration, which earns its place by establishing the design/observation split.

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 carries the full burden of explaining the result shape, and it does so thoroughly: ranked causes with the implicating fact, the cheapest separating observation, the next experiment, eliminated causes, and excluded causes. Nothing an agent needs to know to invoke the tool or interpret its response 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, and the description correctly does not repeat per-parameter definitions. It adds a schema-independent organizing layer by partitioning inputs into design (method, parts, enzymes, primers, host methylation) versus observation (colony counts, screening tally, band sizes, ladder ran), which helps an agent understand which parameters drive verdicts.

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 pair ('Work out why a cloning experiment failed') and enumerates the three accepted symptoms, leaving no ambiguity about scope. It clearly distinguishes this from sibling cloning_simulate: the agent is told this tool consumes both design and observed outcomes and returns ranked causes, whereas simulation covers forward prediction.

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 makes the trigger condition explicit — a failed experiment matching one of the three symptom categories — and implicitly excludes related siblings (virtual_gel, in_silico_pcr, cloning_simulate) by describing its input/output contract. It stops short of explicitly naming alternatives or stating 'use this instead of X,' which would make routing fully unambiguous.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows calling this is safe and repeatable; the description does not repeat that but goes beyond the annotations by explaining failure modes and edge-case rules (LIC chew-back refusal with 'the offending base and position named', slice chew-back overrun/shortfall reporting, mergePreAddedArms returning 'both readings'). The description adds meaningful detail about outputs ('returning the product, the junctions and... junction primers'). However, it doesn't disclose things like the maximum fragment count (24, which is in the schema), runtime behavior, or the fact that output is always a simulation with no persistence. The bar is lower because annotations cover the safety/idempotency profile, and the description does add real behavioral context, so a 3 is fair but on the higher edge.

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

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

The description is a single, information-dense sentence with a useful dash-separated expansion for the LIC edge case. The purpose statement is front-loaded and the chemistry model principle is stated up front. However, it runs long and packs several concepts into one sentence; an agent may need to re-read to parse the LIC clause. It is efficient but could be lightly broken into two sentences to improve scannability. It earns its length.

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 20-parameter, multi-chemistry simulation tool, the description is remarkably complete. It identifies the methods, the return values, the per-method data requirements (insert vs fragments), edge cases and defaults. The output is described (product, junctions, primers) even though there is no output schema. The long per-method schema descriptions carry the detailed parameter semantics, and the description handles the cross-cutting behavioral rules. Nothing an agent needs in order to select and call the tool 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?

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description nonetheless adds critical meaning beyond the schema: it explains the semantic difference between methods that order fragments head-to-tail (gibson/goldengate) vs. those that derive order from homology (infusion), and it explains the significance of the mergePreAddedArms flag with a concrete example (2x tag). It also provides the conceptual logic behind lic's insertNucleotide/vectorNucleotide complement rule and the chewBackLen check. The description ties the parameters to the chemistry model rather than just restating the schema, exceeding the 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 opens with a specific verb ('Assemble fragments by') and an exhaustive list of the assembly chemistries the tool models, and it explicitly distinguishes the tool's core design principle ('Each method is modelled as its own chemistry...'). It clearly names the resource (fragments/vector → assembled product with junctions/primers). Against the sibling list, this stands apart from cloning_diagnose (diagnosis vs simulation), construct_autofix, verify_assembly, and golden_gate_fidelity/from_parts, and the opening sentence makes that differentiation clear without needing to read 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?

The description explains what the tool returns ('product, the junctions and — for the primer-design methods — the junction primers') and gives a working example of the LIC chemistry's behavior, which signals when a user should expect refusal. However, it does not explicitly state when NOT to use this tool or name alternative tools (e.g., when a user should reach for cloning_diagnose, golden_gate_fidelity, or construct_autofix instead). The usage context is clear but the exclusion criteria to siblings are absent. The long method enum descriptions in the schema add a lot of per-method usage guidance, which partly compensates.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate these. The description adds context about the analysis outputs (CAI, adaptiveness, rare-codon, GC3) but does not disclose any unexpected behaviors, side effects, or limitations beyond what annotations provide.

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

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

The description is a single well-formed sentence that efficiently conveys the tool's purpose without redundancy. Every word contributes to meaning, making it easy to scan and understand quickly.

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

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

The tool has moderate complexity (4 parameters, no output schema), but the description does not explain what the tool returns (e.g., numerical values, plots, or a report). It omits details about output format, error conditions, or required input validation, leaving the agent to infer 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 75%, and the schema itself provides clear descriptions for all parameters (e.g., sequence: 'should start in-frame at ATG'). The description adds no new meaning beyond listing the analysis components, so it meets the baseline but does not enhance parameter understanding.

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

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

The description explicitly states that the tool computes Codon Adaptation Index and per-codon relative adaptiveness for a coding sequence against an expression host, including rare-codon and GC3 analysis. This clearly identifies the tool's specific function and distinguishes it from sibling tools like codon_optimize and gc_content.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., codon_optimize for modification, gc_content for simple GC). It does not mention exclusions or prerequisites, such as requiring a valid coding sequence starting with ATG.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the deterministic algorithm ('most-frequent codon per residue'), which reinforces idempotency. It does not mention that coding DNA is translated in frame +1 up to the first stop codon (a key behavior), though that detail is captured in the input schema's protein parameter description. Overall, it adds some useful context beyond annotations.

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

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

The description is a single sentence, front-loaded with the purpose, and contains no superfluous words. It effectively communicates the core function and method in a compact form.

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, and the description does not explicitly state what the tool returns (presumably an optimized DNA sequence). It also omits how the tool handles ambiguous inputs (e.g., protein-only vs DNA) beyond the 'protein' parameter schema. For an agent to know the invocation's result, this is a notable gap, though the tool's simplicity mitigates 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 description coverage is 67%, with detailed descriptions for 'protein' and 'inputType'. The main description adds the term 'expression host' which maps to the 'organism' parameter, but does not further explain the 'organism' enum or default. The schema itself provides sufficient meaning for all parameters, so the description does not need to compensate much.

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 uses a specific verb ('Codon-optimise') with a clear resource ('a protein (or coding DNA)') and states the method ('picking the most-frequent codon per residue'). It clearly distinguishes from siblings like 'reverse_translate' (which does not optimize for a host) and 'codon_adaptation_index' (which computes a score, not an optimized sequence).

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

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

The description implies use for host-specific codon optimization ('for an expression host'), but does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tools like 'reverse_translate' are not mentioned as alternatives, and no exclusions are provided.

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

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

The description contradicts the annotation readOnlyHint=true because the tool clearly modifies the sequence (substitutes codons). According to the rule, a score of 1 is given when description contradicts annotations. The description itself is transparent, but the contradiction undermines trust.

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

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

The description is extremely concise with four sentences covering purpose, scope, limitations, and context. Every sentence earns its place with no redundancy.

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

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

Given the complexity (10 parameters, no output schema) and the annotations with contradictions, the description covers the main purpose and limitations but lacks details on output format, error cases, and parameter interplay. It is minimally adequate but leaves gaps.

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 60%, but the tool description adds no additional information about the 10 parameters. The description does not explain parameter roles, defaults, or interactions beyond what is in the schema, so it fails to add value.

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

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

The description clearly states the tool iteratively substitutes synonymous codons to resolve unwanted restriction sites and other issues flagged by construct_qc, without changing the encoded protein. It distinguishes itself from sibling tools like construct_qc and codon_optimize by focusing on fix-ups after QC.

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

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

The description explicitly advises to re-run construct_qc afterward, implies it should be used after construct_qc detects problems, and states what it does NOT touch (premature stops, GC extremes). This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavior by enumerating the features it flags, which suggests the output will be a report of those issues. It does not contradict the annotations and adds useful context beyond what annotations declare, though it does not specify output format or error handling.

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

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

The description is a single sentence that front-loads the verb 'Lint' and immediately enumerates the checks in a compact list. Every word contributes meaning, and there is zero fluff or redundancy.

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

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

With 8 parameters and no output schema, the description plus the rich schema annotations cover the behavior well. The absence of an explicit return-format description is a minor gap, but the term 'lint' implies a report, and the enumerated checks give a clear picture of what will be flagged. The tool's scope is adequately complete for selection and invocation.

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 every parameter (sequence, gcLow, gcHigh, gcWindow, frameStart, avoidEnzymes, homopolymerMin, crypticOrfMinAa) has a rich description and defaults. The tool description itself does not discuss parameters, but the schema fully carries that burden, 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 description uses a specific verb ('Lint') and a specific resource ('coding DNA sequence'), and enumerates the exact checks it performs: premature stops, internal RBS/polyA motifs, unwanted restriction sites, GC extremes, and repeats. This clearly distinguishes it from siblings like gc_content or restriction_sites, which target only a single check.

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 conveys a clear use case: comprehensive QC of a coding DNA construct. It implies that this tool should be used when multiple sequence features need to be validated at once, but it does not explicitly name alternatives or state when not to use it. Hence it provides clear context without exclusions.

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

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

Annotations already mark the tool as readOnlyHint=true and idempotentHint=true. The description goes well beyond by stating that scores are predicted, not measured; that models are pre-2016 and superseded; that ordering is a ranking aid only; and that scores are null rather than padded for invalid conditions (SaCas9, Cas12a, SpCas9-NG). This fully discloses the tool's limitations and behavior, adding significant transparency.

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

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

The description is front-loaded with the main purpose in the first sentence. Every subsequent sentence adds value (caveats, validity conditions). While it could be slightly more concise by merging some warnings, the trade-off for clarity is acceptable. No superfluous text.

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

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

Despite lacking an output schema, the description explains what the output contains (scored guides), when scores are null, and what the order means. It also handles edge cases (no scan if nuclease omitted). For a tool of this complexity (multiple nucleases, scoring models, validity conditions), the description is remarkably complete without needing to reference external documentation.

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% — all four parameters have descriptions in the JSON schema. The description does not add new parameter-specific details beyond what the schema already provides (e.g., minScore default, nuclease enum, sequence format, searchReverseStrand). According to guidelines, with high schema coverage the baseline is 3, and the description does not improve upon this.

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 explicitly states the tool finds and scores candidate guide RNAs for specific nucleases, which clearly distinguishes it from siblings like crispr_offtarget_check, prime_editing_design, and others. The verb 'Find and score' paired with 'candidate guide RNAs' makes the action and resource unambiguous, and the listed nuclease names differentiate from related CRISPR tools.

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

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

The description provides strong usage context: it warns that predictions are not measured, models are superseded, and ordering is only a ranking aid. It also specifies validity conditions (only SpCas9 with NGG PAM and sufficient flanking context; null scores otherwise). However, it does not explicitly name alternative tools (e.g., more accurate models) or say when to prefer those, leaving the agent to infer from the caveats.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing safety. The description adds meaningful context: it reuses primer_design engine, auto-designs genotyping primers, and handles PAM disruption. No contradictions with annotations. Additional detail about 'real size-shift or sequencing target' adds transparency.

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

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

The description is a single paragraph of about 4 sentences, front-loaded with the core purpose. Every sentence contributes necessary information without redundancy. It efficiently covers modes, nuclease constraints, and secondary functionality (genotyping primers).

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

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

The description explains inputs and high-level outputs but does not specify the exact return format (e.g., what sequences or primer pairs are returned). Since there is no output schema, this information is needed for the agent to understand how to use the result. Otherwise, it covers the main use cases and parameter interactions.

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. The description adds value beyond the schema by grouping parameters into two modes (edit window vs guide cut) and explaining edge cases like Cas12a requiring explicit edit window. It also clarifies the purpose of blockPam and frameStart in the context of PAM disruption.

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

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

The description clearly states the tool builds an HDR donor with homology arms flanking an edit. It specifies two modes: explicit edit window or guide cut site, and mentions it designs genotyping primers. It distinguishes from sibling tools like primer_design by noting it reuses its engine, and covers nuclease-specific constraints (Cas12a needs explicit window). No 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?

The description provides clear guidance on when to use explicit editStart/editEnd versus guide parameters, especially for Cas12a. It also explains PAM-blocking behavior. However, it does not explicitly compare to other design tools like prime_editing_design or base_editing_design, leaving the decision to the agent's broader context.

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

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. Description adds extensive behavioral detail: CFD scoring only for SpCas9 20nt spacer, Pearson correlation 0.40, single mismatch limitation, null returns for unsupported nucleases, and that DNA/RNA bulges are not searched. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and then adds important caveats. It could be slightly more concise (e.g., the GUIDE-Seq comparison detail is valuable but adds length), but each sentence earns its place for capturing nuanced behavior. No waste.

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

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

Given the tool's complexity (3 parameters, no output schema, nuanced behavioral constraints), the description covers purpose, scope, limitations, scoring validity, and exception cases. Without output schema, describing the ranking output would improve completeness, but the description is already thorough for a read-only computation 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 baseline is 3. Description adds value by explaining the broader context: that maxMismatches seeding uses maxMismatches+1 blocks, and that nuclease determines PAM pattern. However, it doesn't explicitly describe the allowed sequence range for protospacer beyond what 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?

Description clearly states the tool screens a protospacer for off-target sites (protospacer match + valid PAM, both strands) against curated lab reference genomes, not whole genomes. This distinctively positions it from sibling tools like crispr_grna_design or primer_specificity, with explicit scope limitations.

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 to use 'the same way primer_specificity is used: a useful sanity check within the covered organisms, not a clearance guarantee.' States what it's NOT (whole genome search, measured data, safe for multiple mismatches + PAM combinations, valid for non-SpCas9 nucleases). Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations indicate read-only and idempotent, but description does not explain what the output or behavior is (e.g., returns stability score, temperature). Without output schema, more detail needed.

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

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

Single sentence, front-loaded, no redundancy.

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

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

Tool is simple with 2 params fully covered, annotations present. Lacks output description, but sufficient for basic understanding.

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

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

Schema coverage 100% with descriptions 'First oligo (5'→3')' and 'Second oligo (5'→3')'. Description adds no extra meaning beyond schema, but baseline is adequate.

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?

Clear verb 'Screen' and resource 'two oligos' with specific purpose 'most stable heterodimer'. Distinct from sibling tools like 'primer_design' or 'oligo_analysis'.

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

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

No explicit guidance on when to use vs alternatives. Implied by name and context, but missing when not to use or examples.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral detail: how band resolution is calculated (size ratio, resolving window, faintness), the auto-enabling of buffer-checked pairs, rejection of unrecognized enzyme names, and the reporting of the actual agarose percentage used. These are valuable beyond the annotations and do not contradict them.

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

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

The description is a single, well-structured paragraph that starts with the core purpose and flows through the process and key nuances. Every sentence adds unique information, with no filler or repetition. It is front-loaded with the primary goal and then provides supporting details.

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

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

For a tool with 7 parameters and no output schema, the description covers all key aspects: what it does, how it works, how to obtain inputs, the ranking criteria, optional parameters, and the meaning of edge cases. It is sufficiently complete for an agent to use it correctly without additional documentation.

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

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

Despite 100% schema description coverage, the description substantially enhances parameter understanding: it explains alternatives (wrong constructs from assembly_outcomes), the auto/always/never nuance of includePairs, the snapping behavior of agarosePercent and its effect on resolution, and the rejection of unrecognized enzymes. This adds meaning beyond the schema definitions.

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 uses a specific verb (pick) and resource (restriction digest) and clearly explains the purpose: distinguishing an intended construct from alternatives on a screening gel. It goes beyond a generic statement by detailing the digestion, band resolution, ranking, and the criterion (separating intended from every alternative), which differentiates it from sibling tools like restriction_sites or virtual_gel.

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 clearly implies when to use it: when you need to select a diagnostic digest for construct screening. It mentions gathering alternatives from assembly_outcomes, which is an explicit usage hint. However, it does not explicitly state when not to use it or explicitly name alternative tools, but the context is clear enough for an agent.

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

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

Annotations already declare the tool read-only and idempotent, so the description only needs to add behavioral context. It adds the input relationship ('from mass ± volume and either a length or a sequence') and the list of conversions, but it does not describe return shape or edge cases. No contradiction with annotations.

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

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

The description is a single, tightly structured sentence that front-loads the domain and lists the outputs and inputs without filler. Every clause contributes meaningful information.

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

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

For a read-only calculator with a fully documented schema, the description provides enough context to understand what the tool does and what inputs it needs. The lack of an output schema means a brief note about the return format would be useful, but it is not critical given the tool's simplicity.

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?

Input schema coverage is 100%, with all eight parameters documented including defaults and enums, so the description does not need to carry parameter meaning. The description adds only a high-level summary of the key inputs, which is helpful but not necessary for parameter understanding.

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

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

The description clearly identifies the tool as a nucleic-acid quantity converter and enumerates the concrete quantities it produces (molar mass, amount, molar/mass concentration, copy number) with the necessary inputs. It does not explicitly distinguish itself from sibling tools, but its domain is distinct enough that an agent can identify its purpose.

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

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

The description implies when the tool should be used: whenever nucleic-acid molarity, concentration, or copy-number conversions are needed. It does not explicitly name alternatives or state when not to use the tool, so some inference is required.

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

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

Annotations already declare readOnlyHint and idempotentHint as true, indicating safe, idempotent operation. The description adds behavioral context by mentioning 'flag caveats', which warns about potential issues (e.g., incompatibility). No contradiction with annotations.

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

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

The description is a single sentence that captures the full purpose, including both the primary action and a note about caveats. Every word earns its place; no unnecessary information.

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

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

Given the tool's simplicity (no output schema, two string parameters), the description fully conveys what the tool does and what it returns (a recommendation with caveats). No missing information for an agent to invoke 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?

Input schema coverage is 100% with descriptions for both parameters ('First enzyme name' and 'Second enzyme name'). The description does not add additional meaning beyond the schema, so 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 description uses a specific verb ('Recommend') and resource ('a single NEB buffer') with clear context ('digesting with two enzymes in one tube'). It uniquely identifies the tool among siblings like 'restriction_sites' which deals with site mapping, not buffer selection.

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 clearly implies when to use: when performing a double digest with two enzymes needing a buffer recommendation. No explicit when-not or alternatives are provided, but the narrow scope makes it distinct from siblings, and the context is clear enough for an agent to infer usage.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses a great deal: per-well failure isolation, duplicate-id suffixing, strict rejection of cross-mode/unknown/out-of-range arguments and offset overrides, row ordering, return of tally and CSV, PREDICTED NOT MEASURED status, and mode-specific blind spots. This is far more transparency than the annotations alone provide.

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 long but front-loaded with the tool's core purpose and the key alternative/mode relationship. It earns most of its length by covering failure modes, validation warnings, and caveats. Minor redundancy exists—the fitAdequate warning appears twice—but given 23 parameters and the complexity of the plate behavior, the length is justified.

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 adequately explains what is returned: one row per sample, headline metric, fit-quality numbers, fitAdequate, input order, tally, and CSV. It also covers failure isolation, duplicate handling, strict argument validation, valid experimental conditions, and mode-specific limitations. Nothing critical is missing for an agent to invoke 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 adds value beyond the schema by explaining cross-cutting parameter behavior: arguments belonging to another mode are rejected, `targetPosition` should be given for a plate or each row reports a different base, duplicate sample ids are suffixed, and the offset override is invalid at plate scale. It does not enumerate every parameter, but it clarifies the semantics that matter most.

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 and resource: 'Quantify a whole plate of edited samples against ONE untreated control trace and return a single sortable table.' It also explicitly ties the tool to three named sibling tools (sanger_indel_spectrum, base_edit_quant, sanger_knockin_quant) and explains they are selected via `mode`, making it impossible to confuse this with the single-sample tools.

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

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

The description gives clear context: it is the plate-scale form of three single-sample tools, the mode selects which quantifier runs, and a 'Valid for' block states the required experimental setup. It does not explicitly say 'use the single-sample tools when you have one sample,' but the distinction is strongly implied and the eligibility constraints are concrete.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool's safety profile is known. The description adds substantial behavioral context: the CSV columns, the plate type placeholder, the well-layout logic (row-major across a 384-well plate), and the assumption of a 5 uL reaction with explicit volume breakdowns. It also discloses that the plate type code is a placeholder, which is a non-obvious caveat. No contradictions exist.

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 dense but not wasteful. The first sentence captures the core purpose, and subsequent sentences provide important details (column names, volume assumptions, plate placeholder, well ordering). Every sentence adds value, though it is longer than strictly necessary and could be split into a summary plus caveats.

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 carries the burden of explaining the return value, and it does so thoroughly: it names the CSV columns, describes plate type placeholders, explains the source plate layout, and flags that the volume scale is not universal. It also references how positions relate to export_plate_layout, which gives richer context. The tool's assumptions and limitations are clearly stated.

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

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

The schema covers 100% of the single parameter 'reactions' with nested object descriptions and a max of 96 entries. The description adds meaningful semantics beyond the schema by explaining how distinct template labels are assigned to unique wells and connecting the parameter to the output layout and volume assumptions. This goes beyond a baseline of 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 begins with 'Generate a downloadable Beckman/Labcyte Echo acoustic-liquid-handler picklist CSV', which clearly states the action (generate), resource (picklist CSV), and target platform (Echo). It distinguishes from siblings like export_plate_layout and export_opentrons_protocol by specifying the exact output format and its association with Echo acoustic dispensing.

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 clear context: it is for PCR reactions on an Echo acoustic liquid handler, and it aligns well positions with export_plate_layout. However, it does not explicitly mention when not to use it or name alternatives such as export_opentrons_protocol, so exclusions are absent. The context is strong, but the guidance could be more direct.

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 indicate readOnlyHint and idempotentHint; the description adds context that the output is a downloadable script with placeholder volumes and labware names, needing review. It does not contradict annotations and provides useful 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?

The description is detailed but front-loads the purpose. It is not overly long; each sentence adds value. Could be slightly more concise, but effectively structured.

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

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

Given no output schema, the description adequately explains what the tool generates and its nature (starting point, not certified), referencing related tools. It covers the usage scenario sufficiently.

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%, but the description adds meaning by noting that master-mix volumes are placeholder constants and that the script uses confirmed labware/pipette API names, enhancing understanding beyond schema.

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

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

The description uses specific verb 'Generate' and resource 'downloadable Opentrons Python Protocol API script', clearly stating the tool's function. It distinguishes itself from the sibling 'export_plate_layout' by referencing well positions from that tool.

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

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

The description implies usage for setting up PCR reactions on a 96-well plate and mentions the script is a starting point, but does not explicitly state when to use vs alternatives (e.g., other export tools) or provide exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, idempotent operation. The description adds behavioral details: row-major well assignment and the fact that the layout is shared with export tools, ensuring agreement. No contradictions with annotations.

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

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

The description is two sentences long, front-loads the core purpose, and adds necessary context about sibling tools. Every sentence contributes value without redundancy.

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

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

Given the tool has one parameter, no output schema, and good annotations, the description adequately covers what the tool does, its input constraints, and its relationship to sibling tools. It could be improved by mentioning error conditions or further behavior details, but it is largely complete for an agent to select and invoke.

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%, and the schema already describes the 'reactions' array and its properties. The description reiterates the fields (name, forward, reverse, template) but adds no new semantic detail beyond the schema. The row-major ordering pertains to output, not parameter semantics.

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

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

The description clearly states the tool assigns PCR reactions to a 96-well plate in row-major order and returns well-assignment data for a plate diagram. It distinguishes itself from related tools by mentioning that export_opentrons_protocol and export_echo_picklist use the same layout, ensuring consistency.

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

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

The description implies when to use this tool (for plate layout and diagram rendering) versus the sibling export tools (for file creation), but it does not explicitly state exclusion conditions or provide definitive guidance on tool selection. The mention of sibling agreement helps, but could be more direct.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the agent knows it is a safe, deterministic operation. The description adds value by specifying the outputs (leaf order, merge trees, z-scored values) and describing the computation, which goes beyond the annotations. It does not mention potential limitations like matrix size or missing data handling.

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 one dense but efficient sentence that covers the core function, algorithmic options, and outputs without redundancy. It is front-loaded with the primary action and every clause contributes to understanding the tool.

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

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

Given the tool's complexity (8 params, no output schema), the description provides a solid overview of inputs, processing, and outputs. It names the return artifacts explicitly, which is helpful. It could be more explicit about the exact data structure of merge trees or edge-case behavior, but the core purpose and data flow are clear.

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?

All 8 parameters have detailed descriptions in the schema (100% coverage), including the meaning of linkage, distanceMetric, and zScoreRows. The main description only briefly summarizes options already present in the schema, so it does not add substantial meaning beyond the schema.

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

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

The description clearly states the tool hierarchically clusters a genes x samples expression matrix and returns specific artifacts (leaf order, dendrogram merge trees, row-z-scored values) for a heatmap visualization. This distinctly differentiates it from sibling tools like gene_expression or volcano_plot_data.

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

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

The context is clear: it is a data-preparation step for the 'Clustered Expression Heatmap visualization.' However, it doesn't explicitly mention when to avoid using it or suggest alternative tools, which keeps it from a 5.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, so the tool's safety is clear. The description adds detail on the report contents (e.g., per-base quality, GC content) but does not reveal additional behavioral traits like output format or potential limitations.

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

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

The description is a single, well-structured sentence that front-loads key information about the tool's purpose and components. No redundant words.

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

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

Despite no output schema, the description does not specify the output format (JSON, text, etc.) or provide details on return structure. For a complex tool generating multiple QC modules, this omission leaves the agent uncertain about what to expect.

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?

Input schema has 2 parameters with 100% description coverage, so the schema already documents them. The description adds no extra meaning beyond the schema, meeting the baseline of 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 clearly identifies the tool as a FastQC-style deep QC report for FASTQ files, listing specific modules (per-base quality, GC distribution, etc.) and mention of warn/fail verdicts against FastQC thresholds. This distinguishes it from siblings like fastq_trim or seqfile_stats.

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 does not explicitly state when to use this tool versus alternatives like seqfile_stats for basic stats or fastq_trim for trimming. Usage context is implied by the tool's purpose, but no explicit when-to-use or when-not-to-use guidance is provided.

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

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

Annotations indicate readOnlyHint=true and idempotentHint=true, and the description adds details about the trimming algorithms (ungapped sliding-suffix adapter match, BWA-style quality trim) and the outcome (drops short reads, returns stats). This adds value beyond annotations.

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

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

The description is a single dense paragraph that efficiently states the purpose, algorithm, and output. It is appropriately sized and front-loaded, though could be slightly more concise.

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

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

Given the tool's moderate complexity and absence of output schema, the description adequately covers purpose, algorithm, and return values (trimmed FASTQ plus stats). It lacks error conditions or input format verification, but schema covers input format.

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. The description mentions the minLength parameter implicitly by saying 'drops reads below a minimum length', but does not add significant meaning beyond what the schema already provides for each parameter.

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

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

The description clearly states it trims FASTQ reads with adapter and quality trimming, specifying the exact algorithm and returning trimmed FASTQ plus statistics. The verb 'trim' and resource 'FASTQ reads' are specific, and it distinguishes from sibling tools like fastq_qc_report which focuses on QC reporting.

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

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

The description implicitly defines usage for trimming FASTQ with adapter and quality trimming, but does not explicitly exclude other use cases or name alternative tools. It provides clear context but lacks exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds minimal extra behavior disclosure beyond 'across all six frames'. No contradictions, but limited added value.

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

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

Single sentence, perfectly concise, and front-loaded with the action. No unnecessary words.

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

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

Given 3 well-documented parameters and no output schema, the description sufficiently states the core function. Could mention output format but not essential for basic use.

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. Description does not add meaning beyond schema; it does not elaborate on parameters like minAaLength or requireStop.

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 uses specific verb 'Find' and resource 'open reading frames (ATG…stop)' with scope 'across all six frames'. This clearly distinguishes it from sibling tools like translate or motif_finder.

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

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

The description implies usage for ORF detection but lacks explicit guidance on when not to use or alternatives (e.g., translate for simple translation). No exclusions or context provided.

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

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

Annotations already declare readOnlyHint and idempotentHint true, so the description does not need to cover safety. It adds value by listing operations (cleaning, conversion, etc.) but does not disclose additional behavioral traits beyond what the schema provides.

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

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

The description is a single concise sentence that front-loads the key operations. It contains no wasted words, but could be slightly more structured for readability.

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

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

Given 6 parameters, no output schema, and good annotations, the description adequately summarizes the tool's capabilities but does not mention the output format or any edge cases. It is minimally complete.

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

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

With 83% schema description coverage, the schema already documents most parameters. The description summarizes the operations (clean, convert, reverse) that map to parameters, but does not add meaning beyond what is 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?

The description clearly states the tool's function: 'Clean, case-fold, DNA↔RNA convert, reverse and line-wrap a sequence.' It specifies the verb (format) and the resource (sequence), and lists distinct operations that differentiate it from siblings like reverse_complement or translate.

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

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

The description implies usage but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to sibling tools are 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?

Beyond annotations (readOnlyHint, idempotentHint), the description discloses the statistical method, multiple testing correction (Benjamini-Hochberg), reliance on bundled reference data (human only), and the default background convention. No contradictions with annotations.

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

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

The description is a single paragraph of three sentences, front-loading the core purpose and method. Every sentence adds essential information without redundancy.

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

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

Given no output schema, the description could specify the output format more explicitly, but it adequately covers the method, data sources, parameter defaults, and limitations. The 100% schema coverage compensates, making the overall description complete enough for its complexity.

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

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

With 100% schema coverage, the description still adds value by explaining the default background meaning (only annotated genes, like g:Profiler) and the default maxTermSize (matching clusterProfiler). This contextualizes parameter behavior beyond their schema descriptions.

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

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

The description explicitly states it performs over-representation analysis for GO terms and Reactome pathways using the hypergeometric test with FDR correction. It clearly identifies the specific input (query gene list vs background) and output (enriched terms), distinguishing it from sibling tools like gene_expression or crispr_grna_design.

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

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

The description provides clear guidance on when to use this tool (for enrichment of GO and Reactome terms) and explicitly notes that KEGG is excluded due to licensing, which helps manage expectations. It does not list alternative tools for KEGG enrichment, but the context is sufficient for an agent to decide.

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

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

Annotations already declare readOnlyHint and idempotentHint, so no destructive behavior. The description adds that the tool returns composition metrics, which is useful but minimal. No mention of edge cases or format of output.

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

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

A single sentence that efficiently communicates the tool's purpose with no unnecessary words. Front-loaded with key information.

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

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

For a simple tool with one parameter and no output schema, the description is adequate but incomplete. It does not specify the output format (e.g., percentages, raw counts), which would help the agent interpret the result.

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

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

The schema has 100% coverage for the single parameter, which is well-described. The tool description adds meaning by specifying what is computed from the sequence, going beyond the input description.

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

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

The description clearly states the tool computes GC content, AT content, and per-base composition for a sequence. It gives specific outputs, distinguishing it from generic sequence tools, though it does not explicitly differentiate from siblings like 'characterize_sequence'.

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

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

No guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use information is provided, leaving the agent without context for selection.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds critical detail: each source fails independently (null/empty for its section) and failures are listed in 'sourceErrors' rather than aborting the call. This goes well beyond annotation information.

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

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

The description is a single sentence structure broken into two sentences, packing a lot of detail. While it is somewhat long, every part is informative and front-loaded with the core function. Minor redundancy ('fanned out' and 'in one call') 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?

Given no output schema, the description adequately covers the expected result shape: per-source sections with potential null/empty, and a sourceErrors list. It names each source's contributions. However, it does not specify whether the output is flat or nested, which could be clarified further.

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

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

There is only one parameter (gene) with 100% schema coverage in the description. The tool description adds no further parameter-level detail beyond what the schema provides, so a baseline score 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 description clearly states that this tool generates a multi-source dossier for a gene/drug-target by aggregating from five distinct sources. It lists each source and what it provides (Open Targets, NCBI/UniProt, ChEMBL, ClinicalTrials.gov, Europe PMC). This distinguishes it from siblings like gene_expression or gene_model which focus on single aspects.

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

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

The description implies 'in one call' for a comprehensive overview, but does not explicitly specify when to use this tool versus alternatives like web_search or individual source tools. There is no guidance on prerequisites or limitations, though the parameter description restricts to human genes.

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 indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds value by detailing the specific data sources (GTEx v8, Human Protein Atlas) and the types of data returned, providing useful context beyond what annotations alone convey. However, it does not mention rate limits or other constraints.

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

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

The description is a single efficient sentence that front-loads the key concept ('tissue-expression fingerprint'). It includes necessary detail without verbosity, though it could be slightly more concise by breaking the list of data types into separate points.

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

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

Given the complexity of returning multiple data types from two databases, the description adequately lists what is included. However, it does not describe the output format or how to interpret the fingerprint, leaving some gaps for an agent without an output 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?

The sole parameter 'gene' is described in the schema with examples of symbol or Ensembl ID. The tool description does not add additional meaning beyond the schema, as it only repeats the concept of a gene. Schema description coverage is 100%, so 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?

The description clearly states the tool returns a 'gene's tissue-expression fingerprint' and lists specific data types (per-tissue median TPM, subcellular localization, RNA tissue-specificity, protein class) from GTEx and Human Protein Atlas. This distinctively identifies the resource and operation, differentiating it from sibling tools that cover sequence analysis, CRISPR design, etc.

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

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

The description implies use when needing gene expression data but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative tool names are provided, leaving the agent to infer the context from sibling names alone.

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 convey readOnlyHint=true and idempotentHint=true. The description adds valuable context: the data is fetched live from Ensembl, uses the canonical transcript, and mirrors the HGVS Converter tool's map. No contradictions, and the extra details help the agent understand behavior beyond annotations.

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

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

The description is a single, efficient sentence that conveys the core function and purpose without superfluous words. Every element earns its place.

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

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

Given low complexity and good annotations, the description adequately explains what the tool does and its source. However, without an output schema, it lacks specifics about the returned data structure (e.g., coordinate lists), which could limit an agent's ability to use the output effectively.

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 only parameter 'gene' is fully described in the schema (100% coverage). The tool description adds no additional meaning beyond the schema, so a baseline score 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 description clearly states it fetches the exon/UTR/CDS structure from Ensembl for a human gene's canonical transcript, with a specific purpose of rendering an exon diagram. It distinguishes from siblings by specifying the source (Ensembl) and transcript selection (canonical), but could more explicitly contrast with similar tools like gene_dossier.

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 lacks explicit guidance on when to use this tool versus alternatives. It mentions a use case (rendering an exon diagram) but does not provide exclusions, prerequisites, or compare with other tools from 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 indicate read-only and idempotent behavior, and the description adds context about the transparent methodology and its limitations (not reproducing NEB's exact values). No contradictions. The description enhances understanding 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?

The description is two sentences long with no filler. The first sentence clearly states the main function and outputs, while the second clarifies limitations. Very efficient.

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

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

Given the complexity (multiple parameters, optional comparisons, no output schema), the description covers the essential workflow, inputs, and what the tool does not provide. It is sufficient for an agent to understand usage without needing the output 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 coverage is 100% with each parameter described well. The description does not add new meaning beyond the schema, but provides context for the overall scoring purpose. 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?

The description clearly states the tool scores candidate overhang sets against real ligation data, enumerates specific outputs (specificity, weakest link, risky pairs), and distinguishes itself from alternatives like NEB's undisclosed methodology. It is specific and sets clear boundaries.

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 mentions optional comparison with named sets but does not explicitly cover when not to use the tool or offer direct alternatives. However, it does clarify what the tool does not do (reproduce NEB percentages), which helps guide appropriate use.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, which already cover safety and idempotency. The description adds meaningful behavioral context beyond annotations: it explains that the fragment released carries no recognition site, that the assembly order is an output, and that a set of overhangs that doesn't close into a cycle produces no product. This is valuable disclosure of the tool's internal logic without contradicting any annotation.

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 long but well-structured: it front-loads the core action, then explains the mechanism, output behavior, and finally the distinction from a sibling. Each sentence carries necessary information for a complex reaction. It could be slightly tightened, but the structure is logical and the density is justified by the technical depth.

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

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

Given the tool's complexity and the absence of an output schema, the description adequately covers the key expectations: what the tool does, why the sites are needed, how the order is determined, and what happens when overhangs don't close. It does not describe the exact return format, but the description implies the assembly order is the output. For an agent calling this tool, the essential context is 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 schema description coverage is 100%, so the baseline is 3. The description adds only conceptual context about overhangs dictating order and enzyme-specificity, but these points are largely implicit in the schema (e.g., 'Each needs two Type IIS sites facing INWARDS'). It does not add new syntactic or semantic details beyond what the schema already provides, so a 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 description states a specific verb and resource: 'digest pre-domesticated part plasmids with a Type IIS enzyme and assemble them in the order their OVERHANGS dictate.' It clearly distinguishes the tool from cloning_simulate's goldengate method, which is named explicitly. The purpose is unambiguous and sets it apart from siblings without needing to inspect 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?

The description explicitly contrasts this tool with cloning_simulate's goldengate method, stating that the other tool 'designs the primers that ADD the sites to BARE parts, assembled in the order you list them.' This gives clear when-to-use and when-not-to-use guidance. It also explains the consequence of a mis-ordered assembly, which informs the user on what to expect.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description details internal processes (live Ensembl maps, MANE crosswalk, 3'-rule normalization) and refusal reasons, adding significant behavioral context. No contradiction with annotations.

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

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

Every sentence is informative and earns its place. The description is well-structured with a clear purpose, detailed behavior, and explicit limitations, all without unnecessary verbosity.

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

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

Given the tool's complexity and high parameter documentation, the description covers most aspects. However, it lacks explicit mention of the output structure (e.g., what fields are returned), which would enhance completeness for an output-schema-less 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?

The sole parameter 'variant' has full schema coverage, but the description adds crucial context: required format with examples, supported accessions and edit types, which goes beyond the schema definition.

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

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

The description clearly states it converts HGVS 'c.' descriptions to genomic coordinates and predicts protein effects. It specifies supported accessions (gene symbol, RefSeq, Ensembl) and edit types, distinguishing it from sibling tools like variant_annotate.

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

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

The description explicitly states when to use the tool and lists clear refusal cases (circular/mitochondrial genomes, RNA/protein input, uncertain syntax, etc.), providing excellent guidance on when not to use it.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating safe, idempotent polling. The description adds value by detailing the response format and a key behavioral trait: normalization of mapped ids regardless of target database. No contradictions with annotations.

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

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

Two efficient, front-loaded sentences. The first states purpose, the second details response lifecycle. No unnecessary words. Perfectly concise for the complexity.

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

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

For a simple polling tool with one parameter and sufficient annotations, the description is complete. It explains the return value structure and a notable behavior (normalization). No output schema exists, but the description adequately covers what is returned.

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

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

With schema description coverage at 0%, the description must clarify the parameter. It mentions 'job submitted via id_map_submit', implying the jobId comes from that submission. However, it does not specify format or constraints beyond what the schema provides (type string, required). It adds marginal meaning.

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

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

The description clearly states the tool's purpose: checking a UniProt id-mapping job submitted via id_map_submit. It specifies the behavior (returns status while running, mapped ids and failed ids when finished), and distinguishes it from the submission tool id_map_submit. The verb 'Check' and resource are explicit.

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

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

The description explicitly ties usage to a prior id_map_submit call, providing clear context. It doesn't explicitly state when not to use the tool, but the complementary sibling relationship is evident. This is sufficient guidance for an AI agent.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by specifying the 1000 ID limit and that it returns a jobId immediately, but does not add significant behavioral context beyond what annotations imply. No contradiction with annotations.

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

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

The description is two concise sentences, front-loaded with the core action and examples, and includes the important note about polling. No wasted words.

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

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

For a submission tool, the description is complete: it explains what it does, the limit, the return value (jobId), and how to get results (poll id_map_poll). The schema covers all parameter details, and the sibling tool for polling is referenced.

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 very detailed parameter descriptions. The description adds some examples of valid hops but does not significantly enhance parameter understanding beyond the schema. 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 description clearly states the tool submits up to 1000 IDs to UniProt's ID mapping service for a single confirmed-safe hop, with concrete examples like Gene_Name -> UniProtKB-Swiss-Prot. It distinguishes itself from the sibling id_map_poll by stating it returns a jobId to poll.

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 when to use the tool: for a single hop mapping. It mentions polling with id_map_poll and implies multi-hop scenarios require chaining, though this is detailed more in the input schema. Explicit exclusions for non-safe hops are in the schema but not in the description.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description goes far beyond that. It explains the non-templated 5' tail behavior, clarifies that primers prime on the 3' end, defines start/end as template-derived span and length as including tails, and mentions the 'features' field and per-end annealedLength/tailLength in the output. This rich behavioral context, including edge cases like circular templates and search-window semantics for maxProductLength, adds substantial transparency.

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

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

The description is dense but every sentence earns its place. The core purpose leads, followed by the tail mechanism, then parameter semantics. There is no fluff or repetition, and technical details like the start/end vs length distinction are packed efficiently. It is appropriately long for the complexity but remains tightly structured.

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

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

Given 6 parameters, no output schema, and a complex tool, the description covers everything an agent needs to call it correctly: primer orientation, tail handling, circular behavior, mismatch tolerance, and even the semantics of maxProductLength plus the response fields (features, annealedLength, tailLength, suppressedByLength). It is fully self-contained despite the absence of an output 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?

The schema already provides descriptions for all 6 parameters (100% coverage), but the description adds crucial nuance: it clarifies that reversePrimer is optional and order-independent, explains the tail interpretation for forwardPrimer, and reinterprets maxProductLength as a 'SEARCH WINDOW' that discards products via suppressedByLength. This goes well beyond the schema to resolve ambiguity and correct potential misinterpretations.

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 immediately states the specific verb and resource: 'Predict PCR products for a template and a pair of primers'. It further distinguishes itself by listing key capabilities (IUPAC-aware, allows mismatches, handles circular templates) that separate it from primer design tools like primer_design. This makes its purpose clear and non-confusable with siblings.

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 explicit. The description says what it does but never directly states when to use it over alternatives or when not to use it. The only hint is the mention of 'whole-plasmid inverse PCR' in the maxProductLength parameter, which implicitly ties it to cloning workflows but does not contrast with other sibling tools. There is no explicit when/when-not guidance.

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

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

Annotations already provide readOnlyHint and idempotentHint, so the bar is lowered. The description adds valuable behavioral context: the antisense-strand interpretation, mismatch-class differences between the two primers, grading by Kwok et al. 1990 yields, and reuse of the Tm engine—none of which is in annotations.

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

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

The description is a single dense run-on sentence that front-loads nearly all details without structural breaks. It is information-dense and not wasteful, but its lack of paragraphing or bullet-like separation makes it harder to parse quickly.

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 complex 8-parameter design tool with no output schema, the description covers the core algorithm, key design constraints, and reporting distinction without explaining exact return values. It is substantially complete for an experienced user, though an explicit output description would have been useful.

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. The description enriches parameter understanding by explaining why FAM/HEX tails are assigned per allele, how amplicon range relates to the reverse primer, and how the secondary mismatch interacts with the natural allele mismatch—value beyond the schema's property descriptions.

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

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

The description uses a specific verb ('Design') and resource ('KASP/ARMS allele-specific genotyping primers for a SNP'), and details the two allele-specific forward primers plus common reverse primer. This clearly distinguishes it from generic primer_design or aso_design siblings.

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

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

The description implies usage for SNP genotyping and KASP/ARMS applications, but it does not explicitly state when to prefer this tool over sibling tools like primer_design or aso_design, nor does it mention exclusions. Context is present but not fully actionable.

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 declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral details beyond that: it 'flags the two things that actually go wrong on a bench' (pipette volume reliability and insufficient room for buffer/enzyme), and explains the conversion logic ('a shorter insert at 3 molar equivalents goes in at LESS mass than the vector'). This enriches understanding of what the tool returns and its design intent, without contradicting annotations.

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

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

The description is a single dense paragraph that is front-loaded with purpose, then features, then a critical caveat. It is informative without being verbose, but it could be slightly more concise by trimming the last sentence's redundancy. However, every sentence earns its place by conveying essential context.

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

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

Given the complexity (9 parameters, all schema-documented) and no output schema, the description adequately covers what the tool computes (volumes, pmol, ng), its multi-insert capability, and the important error flags. It tells the user what to expect without needing an output schema. The completeness is high for a calculation tool with clear annotations.

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% for all 9 parameters, each with a description. The tool description adds conceptual meaning beyond the schema, such as how molar equivalents map to mass and the role of length and stock concentration. While it doesn't detail each parameter further, it provides the underlying logic that ties them together, which is valuable for an agent selecting parameters correctly.

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

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

The description clearly states the tool's purpose: 'Work out how many microlitres of vector and insert to pipette to hit a target molar ratio' – a specific verb and resource. It distinguishes itself from sibling DNA tools by emphasizing support for multi-fragment assemblies (Gibson, Golden Gate, MoClo) and its focus on pipetting volumes, which is not offered by generic calculators like dna_molarity or simulators like cloning_simulate.

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?

Provides clear context on when to use: 'Handles one insert or several with independent equivalents (Gibson, Golden Gate, MoClo)' and explains the molar ratio concept. It implies usage for assembly setup but does not explicitly name alternatives or exclusions. However, the context is sufficient for an agent to distinguish it from other tools in the suite.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds methodological context (nearest-neighbour, Wallace rule, Schildkraut-Lifson) but does not detail return format, the pass/fail gate for targetTm, or potential limitations like sequence length restrictions beyond the 14 nt recommendation.

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

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

The description is a single, information-dense sentence that front-loads the core purpose. It includes relevant details without excessive filler, though the listing of multiple thermodynamic methods makes it slightly heavier than necessary.

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 calculation tool with 7 parameters and no output schema, the description explains what it computes and the methodology, but it does not explain the optional targetTm pass/fail gate or what the response contains beyond molecular weights. It also lacks explicit comparison to sibling oligo analysis tools, which would help in a rich tool ecosystem.

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 parameter descriptions, so the baseline is 3. The description's mention of 'supplied reaction conditions' and 'molecular weights' adds context to parameters like mgMM and oligoNM but does not directly map to parameter syntax or required input formats.

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 'Primer/oligo melting temperature' clearly stating the tool's function. It further specifies the calculation method (nearest-neighbour SantaLucia 1998) and includes molecular weights, distinguishing it from sibling tools like primer_design or cross_dimer.

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

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

The description implies usage for Tm calculation and offers some guidance by noting the 14 nt length recommendation and the Wallace rule for shorter oligos. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, such as when to choose primer_design or oligo_analysis.

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

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

The description adds behavioral context beyond annotations by specifying overlapping matches, allowance of mismatches, and dual-strand search. Annotations already indicate read-only and idempotent behavior, so the description effectively supplements these with operation details.

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

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

A single 13-word sentence that front-loads the action and includes key qualifiers. Every word contributes meaning, with no redundancy or filler. Ideal conciseness for quick parsing.

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

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

The description lacks output format details (e.g., positions, list of matches) and does not address limits (e.g., sequence length). With no output schema, the description should compensate, but it does not, leaving an AI agent with incomplete invocation context.

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?

Input schema has 100% description coverage, so the schema already documents all four parameters. The description adds no new semantic information beyond rephrasing the tool's purpose. Baseline score of 3 is appropriate since schema carries the burden.

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

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

The description clearly states the verb 'Find' and the resource 'occurrences of an IUPAC motif', with specific qualifiers like overlapping, either strand, and allowing mismatches. This makes the tool's exact functionality unambiguous and distinguishes it from sibling tools like 'find_orfs' or 'restriction_sites'.

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

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

The description implicitly defines when to use this tool (motif finding in nucleotide sequences) but lacks explicit guidance on when not to use it or which sibling tools are alternatives. An agent could reasonably infer usage, but clearer direction would improve selection confidence.

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

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

Annotations already indicate readOnlyHint and idempotentHint, so no destructive behavior. The description adds value by specifying input constraints (up to 25 sequences) and output features (consensus, per-column conservation), which are not in annotations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and key details. Every word is informative, with no unnecessary content.

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 single-parameter tool with robust annotations and no output schema, the description adequately covers input constraints and output features. Minor omission: no explanation of the alignment algorithm beyond 'center-star', but this is acceptable given tool simplicity.

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% for the single parameter 'input', which already specifies multi-FASTA format and upper limit. The description repeats this, adding no new semantic detail; 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?

The description clearly states the tool performs multiple sequence alignment using the center-star method on a multi-FASTA input, producing consensus and per-column conservation. This explicitly distinguishes it from the sibling pairwise_alignment tool.

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

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

The description implies usage for aligning multiple sequences, contrasting with pairwise alignment, but does not provide explicit guidance on when to choose this over alternatives or mention any exclusions.

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

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

The description explains key behaviors: it searches combinations rather than isolated pairs, and on failure it identifies the problematic target. No side effects are mentioned, but annotations indicate read-only and idempotent, so the description aligns with expected behavior without overpromising.

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

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

The description is concise and well-structured in two sentences, packing essential information about constraints, search strategy, and failure behavior without unnecessary detail. It avoids redundancy with the schema.

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

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

Given the schema and annotations, the description provides sufficient context about why multiplexing is challenging, what the tool does about it, and what happens when no panel exists. It doesn't discuss output format, but since there's no output schema, the description's 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?

The schema already provides 100% coverage and detailed descriptions for all parameters (including defaults like 'dimerThresholdDG' and 'candidatesPerTarget'). The description doesn't add parameter-specific information beyond what's in the schema, so it doesn't improve on the 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 clearly states the tool's function: selecting one primer pair per target for a multiplex panel with constraints like no cross-dimer, amplicon resolution, and uniform annealing temperature. It distinguishes from single primer design by highlighting the combinatorial search, making its purpose unambiguous.

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

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

The description implicitly contrasts with single-primer tools (e.g., 'primer_design') by emphasizing the panel-level search and the failure mode that names the target that cannot be multiplexed. While it doesn't explicitly say 'use this when you need multiplex', the context makes it clear when this tool is appropriate versus alternatives.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, so safety is clear. Description adds that it returns base-pair diagrams and warnings, which is useful but does not elaborate on computational cost or limitations.

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

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

Single sentence that is front-loaded with key outputs (Tm, ΔG, ΔH, ΔS, screening, diagrams, warnings). No unnecessary words.

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

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

No output schema provided, so description must explain return values. It lists thermodynamics, screening results, and diagrams, which is sufficient but lacks detail on format or structure (e.g., whether it returns a report, JSON, or visualization).

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 covers 100% of parameters with descriptions (e.g., mgMM, naMM, dntpMM, oligoNM, sequence). The description only restates that it uses sequence and cation concentrations, adding no new meaning beyond the schema.

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

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

Description clearly states the tool performs full oligo analysis including nearest-neighbour thermodynamics (Tm, ΔG, ΔH, ΔS) and secondary structure screening (hairpin, self-dimer) with diagrams and warnings. This distinguishes it from siblings like 'melting_temperature' which only calculates Tm.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., 'melting_temperature' for just Tm, 'cross_dimer' for heterodimers). The description implies comprehensive analysis but does not state use cases or exclusions.

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

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

Goes well beyond annotations (readOnlyHint, idempotentHint) by disclosing that results are predicted, not measured; that ΔG has ~kcal/mol uncertainty; that MFE structure accuracy degrades with length; and that the model ignores concentration and salt. No contradiction with annotations.

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

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

Description is fairly long but every sentence adds essential information: purpose, output, comparison, limitations, validity range, parameter usage advice. Front-loaded with core purpose. Could be slightly more streamlined, but no fluff.

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

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

Given the complexity of the tool and absence of output schema, the description thoroughly covers what it computes, parameter sets, temperature, comparators, limitations, validity (≤200 nt), and what it cannot do (ignore concentration, salt, cycling). Provides sufficient context for an agent to use and interpret results.

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

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

Schema already covers all 5 parameters with high-quality descriptions (100% coverage). Description adds contextual value for temperature (should be annealing temperature) and partition (costs second pass, more honest for competing structures). Modest added value beyond schema, justifying a score above 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?

Description explicitly states it computes minimum-free-energy structure and ΔG for one or two oligos (hairpin/dimer), contrasting with sibling oligo_analysis's fast stack-sum screen. It clearly defines the resource and action, and avoids tautology.

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?

Provides explicit when-to-use guidance: full loop model for short oligos (≤200 nt), contrasts with oligo_analysis, warns about uncertainty and limitations (not measured, no PCR failure prediction, ignores concentration/salt/cycling), and advises using partition for ensemble free energy when competing structures exist.

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 mark the tool read-only and idempotent; the description adds the output style (conflicts ranked, complete counts), the two-bar 3' vs internal ΔG rule, and the caveat that values are nearest-neighbour calculations, not reaction predictions. This is useful behavioral context beyond the annotations and no contradiction is present.

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 five sentences and all of them carry information: purpose, pool-level comparison with a concrete scale example, differentiation from the design tool, the scoring rule, and the calculation caveat. The 51-primer example is illustrative but slightly expandable; still, nothing is redundant.

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 read-only screening tool with rich annotations and a fully documented schema, the description adequately covers what the tool does, its relationship to close siblings, and its output style. With no output schema, the 'conflicts ranked' and 'COUNTS always complete' statements help fill that 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?

With 100% schema description coverage, every parameter is already documented in the schema. The description adds conceptual context for the two ΔG thresholds, but no additional per-parameter semantics beyond what the schema provides, 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?

The description uses a specific verb ('Screen') and a defined resource ('a whole set of oligos you already have'), enumerates the checks performed (cross-dimers, hairpins, self-dimers, duplicates, Tm spread), and explicitly contrasts with cross_dimer and multiplex_panel_design, making sibling differentiation clear.

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 explicitly frames this tool as the pool-level counterpart to cross_dimer, notes the scale difference through a concrete example, and warns against confusing it with multiplex_panel_design by specifying that the tool consumes already-ordered oligos rather than designing them. This gives an agent clear selection criteria.

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

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

Annotations already indicate readOnlyHint and idempotentHint, so the agent knows it is safe and idempotent. The description adds that unmapped symbols are reported in 'unmapped' and never silently dropped, which is valuable beyond the annotations. No contradictions.

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

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

The description is extremely concise with only two sentences, front-loaded with the key verb 'Look up'. Every sentence provides essential information without redundancy.

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

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

Given that there is no output schema and the tool is a lookup, the description hints at the output structure by mentioning the 'unmapped' field. However, it does not fully describe the response format for successful mappings, which could be improved. Still, it is fairly complete for the complexity level.

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 parameters are well-documented. The description adds context about the 50-symbol limit and the behavior for unmapped results, which goes beyond the schema. It also explicitly mentions the Ensembl REST endpoint, adding operational context.

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

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

The description clearly states the tool's purpose: looking up orthologous/paralogous genes for up to 50 gene symbols across species via Ensembl's homology-by-symbol endpoint. It uses a specific verb and resource, and distinguishes itself from sibling tools by its focused functionality.

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

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

The description implicitly guides when to use this tool (when needing orthologs/paralogs for gene symbols) and mentions the source endpoint and constraints. No explicit exclusions or alternatives are given, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds valuable behavioral details about the algorithms and, notably, the semiglobal behavior (terminal overhangs free, no smearing of partial reads). It does not describe the return format, but this is not a major gap given the read-only nature.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and packs in algorithms, scoring, and gap model without wasted words. It is concise yet comprehensive, well-structured for quick scanning.

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 complex tool with 7 parameters and no output schema, the description covers the key aspects: modes, scoring, and gap penalties. It does not explicitly state the output format, which would be helpful, but the core functionality and behavioral nuances are sufficiently described. Overall, it is complete enough for an agent to understand when and how to use 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema; it mentions affine gap costs and scoring modes, but the schema already provides detailed descriptions for each parameter. No significant extra value is added.

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

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

The description clearly states the tool's purpose: pairwise alignment of two sequences, with specific algorithm names (Needleman-Wunsch, Smith-Waterman, Gotoh) and scoring details. It distinguishes itself from multiple sequence alignment by focusing on pairwise, and the specificity of algorithms and modes leaves no 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?

The description implies usage context through the three modes (global, local, semiglobal), each explained in terms of when they are appropriate (e.g., semiglobal for fitting a partial read to a reference). It does not explicitly name alternatives or when not to use, but the context is clear enough to guide selection.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by specifying that the tool extracts locus, definition, features, and sequence, which is not obvious from annotations alone. However, it does not disclose error handling, input validation requirements, or output format details.

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

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

The description is a single, well-structured sentence of 12 words. It front-loads the verb and outcome without any redundant or unnecessary information, earning every word.

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

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

For a simple parser with one parameter and no output schema, the description is fairly complete. It explains what the tool does and what data is extracted. Minor gap: it does not describe the return format (e.g., JSON object structure), but overall adequate given the tool's simplicity.

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% and the parameter description already mentions the GenBank flat file format. The tool description reinforces this but does not add new meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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