jean — Molecular Biology & Genomics

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral value beyond that: output ordering ('steepest first'), the Infinity edge case for identical fingerprints with differing activities, and 0-based indices.

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?

It is a single dense sentence, but it is front-loaded with the method name and citation, then the formula, ordering, edge case, and index convention. Every clause carries information, though the run-on structure slightly hurts 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?

An output schema exists, so return values need not be explained, and annotations cover safety. The description supplies the metric definition, ordering, edge case, and index convention, leaving only cross-tool routing unaddressed for this fairly complex five-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 description coverage is 100%, so the schema already documents all five parameters, including the scale enum and the _files/_subject shapes. The description reinforces the pairing of molecules and activities but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description names the exact analysis (SALI activity cliffs, with a literature citation) and pins down the metric: activity difference over one minus Tanimoto similarity of RDKit path fingerprints. An agent knows precisely what is computed, though no sibling (e.g. matched_molecular_pairs, cluster_molecules) is named to contrast against.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The input constraint ('a list of small molecules with one activity each') hints at a prerequisite, but the agent is left to infer when this tool is preferable to the other molecule-analysis siblings.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description goes far beyond that by disclosing that the signal is untouched, that existing coordinates (trims, hand corrections, annotations) are carried across the peaks, that sequence/consensus/verification/exports all follow, and that it reports what moved and what could not be placed.

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 mutating action is front-loaded in the first clause, and every sentence carries real information (what changes, what does not, what to use instead). It is dense with em-dash asides and runs slightly long for the amount an agent must retain.

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

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

An output schema exists, so return values need not be spelled out, and the description still flags that it reports moved/unplaceable calls. The mutation semantics and sibling routing are covered; the only gap is how a trace comes to be 'open' (load_trace/list_traces) and whether the change is persisted.

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 the mode/table/min_ratio parameters are fully documented in the schema itself (including when min_ratio is ignored). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Replace a Sanger read's own base calls with TraceTuner's, on the trace that is open') and names the scope of consequences. It explicitly separates itself from the sibling call_bases_from_trace, so an agent can pick between them without opening either 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?

Includes a precondition ('on the trace that is open') and an explicit alternative with its selection condition: use call_bases_from_trace to ASK what the re-call says without changing the read. No exclusion is given for the adjacent call_mixed_bases_from_trace, which overlaps with the het/mix modes, so this is clear but not complete.

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 a safe read-only, non-open-world profile, so the bar is lower, and the description still adds real behavior: no threshold and no verdict, refusal rather than guessing when multiple alignments exist, the dense-window warning for dbSNP variants, and the interpretation of high mismatch rates as a wrong-assembly signal. That is meaningful context beyond the annotations, though permission/authentication needs and return shape are left to the output schema.

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

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

The purpose is front-loaded in the first clause, and the remaining sentences mostly earn their place by explaining defaults and the meaning of a mismatch rate. The prose is dense and meandering in places (the 'exactly as the panel offers it' and 'as a fact rather than as a judgement' phrasings), so it is not maximally tight, but nothing is gratuitous.

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

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

An output schema exists, so return values need no explanation, and annotations carry the safety profile; the description covers the remaining behavioral burden well (defaults, refusal semantics, interpretation guidance, variant-density caveat). Only the relationship to sibling tools is genuinely missing, which keeps it short of a 5.

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 a 3 would be the baseline, but the description adds interpretive meaning the schema lacks: variants is off by default because it is 'a third layer' that can hold thousands of rows, and gene_track's default (RefSeq Select) 'carries no mitochondrial genes at all — RefSeq Curated does.' The reference default of 'No reference' and the window default are also restated with intent.

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: 'Read an alignment window and say how well its reads agree with the reference underneath them,' and even names the concrete outputs (compared and differing base counts, gene models, dbSNP variants). It is clear what the tool produces, but it never names or contrasts a sibling like alignment_window or compare_reads_to_reference, which also operate over alignment windows, so sibling differentiation rests on inference.

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 context is implied rather than stated: the description explains defaults (unset alignment, 'No reference') and warns that a tens-of-percent rate usually means a wrong assembly, which hints at when the tool is diagnostic. However, it never says when to choose this over alternatives such as alignment_window or compare_reads_to_reference, so an agent must infer the selection rule.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds some behavioral context (mirrors the pane's window/filters/cap) but does not disclose refusal conditions, cost, or sampling semantics beyond what the schema already spells out.

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?

Reasonably short and front-loaded with the core action, but the second sentence is opaque jargon ('the way the pane's own hand-offs do') whose meaning is not self-evident to an agent. Half the text is spent on a metaphor rather than actionable detail.

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

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

An output schema exists, so return values need not be re-explained. However, for a 9-parameter tool with nested objects, the description leaves the integration path ('wire `reads` into…') vague and does not mention what an agent should expect when the window exceeds the cap or multiple alignments exist — details present only in the schema.

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

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

Schema description coverage is 100%, so every parameter (locus, min_mapq, max_reads, hide_* flags, alignment, _subject) is already documented in the schema. The description only gestures at 'the same window, filters and record cap the pileup draws' without adding syntax or defaults beyond that. Baseline 3 applies.

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

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

States a specific verb and resource — read one window of a BAM/SAM in this project — and enumerates the three outputs (reads, depth, pair/library info). It is clear what the tool does and that it mirrors the pileup pane's window, but it never names a sibling (e.g. browse_region, alignment_agreement) to disambiguate the overlapping region-inspection space.

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 closing sentence ('Wire `reads` into an alignment or a screen the way the pane's own hand-offs do') implies the downstream workflow but gives no explicit when-to-use, when-not, or named alternative relative to the many other alignment/region tools. Usage must be inferred from the pane metaphor.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed world), so the description wisely spends its budget on behavior instead: Needleman-Wunsch, free end gaps, IUPAC substitution matrix, and the guarantee of identical output to the trace panel. It also discloses the output form ('two gapped rows'). No failure modes or limits are mentioned, keeping it at a strong 4.

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

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

Three sentences, purpose front-loaded, then algorithm detail, then the parameter default. Every clause carries information (algorithm, gap policy, matrix, scope, default) and nothing is padding.

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

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

An output schema exists, so return values need not be described, and the description still names the output form. Combined with algorithm, scope, and default-parameter behavior, an agent has everything needed to invoke this correctly on a single read.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description's note that `reference` unset means the current record largely repeats the schema's own wording, adding little new syntax or 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?

States a specific verb+resource with explicit scope: 'Pairwise-align ONE sequencing read against a reference'. The 'ONE' qualifier and the pairwise framing distinguish it from the multi-sequence/alignment siblings (align_sequences, ebi_align, map_reads). The core operation is unambiguous from the first clause.

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

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

Gives the downstream reason ('so the read can be graded') and the explicit default rule for `reference` when unset, plus a reproducibility rationale (same call as the trace editor). It does not name when to prefer a sibling such as align_sequences or compare_reads_to_reference, so context is clear but exclusions are absent.

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, destructiveHint=false, openWorldHint=false; the description adds genuine context beyond that — that the engines are not fallbacks for each other, that poa emits its own consensus row, and warnings like naming the wrong substitution matrix 'is not an error the engine can raise'. It stops short of describing return structure, which the output schema covers.

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

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

Front-loads the core distinction (two non-interchangeable engines) before the supporting detail, and every sentence about engine behavior earns its place. It is dense and somewhat long, overlapping with parameter descriptions, so not a clean 5.

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

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

For a 17-parameter tool with no required params, nested objects and an output schema, the description covers engine choice, engine-specific constraints and input sourcing well. A reader has enough to invoke it correctly, with parameter details and returns delegated to the schema.

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

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

Schema description coverage is 100%, so parameter meaning is already carried by the schema. The description reinforces the engine-to-parameter mapping and input wiring, but adds little syntax or semantics the schema lacks.

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

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

States a specific verb+resource (multiple-sequence alignment) and then distinguishes the two engines by the question each answers, in terms an agent can act on. It is clearly separable from siblings like align_read or ebi_align because it declares itself the multi-sequence family/pile aligner.

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

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

Gives explicit engine-selection guidance: poa for 'a pile of reads over one locus', progressive for 'a FAMILY of homologous genes'. It also explains how to supply input (wire upstream outputs into sequences or name library documents). It stops short of naming sibling alternatives such as align_read for pairwise work, so not a full 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 declare read-only/non-destructive analysis, and the description goes well beyond them: it discloses what each engine computes, that only 'plate' classifies, that 'curve' skips plate normalisation and produces no verdicts, and that replicate spread rides along with every engine because it describes readings not method. It stops short of describing performance or output shape, but the behavioural disclosures are substantial.

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

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

Front-loads the key fact (three engines, different questions, no fallback) before enumerating each engine, so the agent gets orientation immediately. It is dense and delivered as one long paragraph, but every clause carries information that would otherwise be lost.

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 29-parameter, three-engine tool with an output schema present (so return values need not be re-explained), the description supplies the engine semantics and the replicate-spread rule that an agent needs to choose correctly. The main omissions are cross-sibling positioning and any note on input-table requirements beyond what melt_table's own description states.

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

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

Schema description coverage is 100% and each parameter already carries rich semantics (including 'Only applies when engine is X'). The description reinforces the engine-choice framing and the engine-independence of the replicate parameters, but this largely restates what the schema already documents, so the baseline of 3 holds.

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

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

States a specific verb+resource ('Melt curves to melting temperature') and then precisely distinguishes the three engines by the question each answers, explicitly noting none is a fallback for another. An agent can tell the engines apart — and understand that this is a verdict-producing analysis vs. a raw peak profile — without opening any schema.

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

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

Gives strong intra-tool routing: 'plate' for verdicts, 'vertex' for a sub-grid Tm, 'curve' for peak areas, with the explicit warning that these are not interchangeable. It does not, however, contrast this tool with siblings like melt_profile or melting_temperature, so cross-tool selection is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description goes well beyond that by disclosing refusal semantics ('a build with no cached track is refused by name rather than answered empty'), provenance reporting ('every track answers with its authority, table and retrieval date'), coordinate convention, and the counting rule that balanced/unclassified variant types are never dosage evidence but are reported instead.

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?

Purpose is front-loaded in the first sentence, and the coordinate convention is placed last where it belongs. The first sentence is a long enumerated run-on that requires re-reading, and a few parentheticals ('the only case where a residue-level design is honest') are interpretive rather than operational, keeping it from a 5.

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

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

An output schema exists, so the description need not document return values, yet it usefully characterizes what each track reports. With 8 parameters (4 required), a nested _subject object and 100% schema coverage, the description plus schema give an agent enough to call the tool correctly; the missing piece is explicit routing against sibling region/variant tools.

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 genuinely adds meaning on top: it explains that 'tracks' controls which of genes/dgv/segdups is read and that the coding verdict is coupled to the 'genes' track, and it restates the build-refusal behavior tied to the 'build' parameter. It adds little for the coordinate parameters beyond what the schema already says (1-based, inclusive), so it is not a 5.

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

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

The description names a concrete verb ('say what a genomic region holds') and enumerates exactly what is returned: overlapping genes and RefSeq transcripts, contained complete CDS, DGV structural variants with frequencies, and segmental-duplication/paralogue similarity. That is far more specific than a restatement of the name. It stops short of a 5 because it never distinguishes itself from plausible siblings such as browse_region or lookup_variant, which an agent could reasonably confuse it with.

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

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

Usage is only implied: the agent can infer this is the tool for characterizing a coordinate interval, and the note that tracks defaults to all three and that the coding verdict comes with 'genes' guides how to scope a call. However, there is no explicit when-to-use versus when-not, no prerequisite statement, and no alternative sibling is named for region-level questions.

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, destructiveHint false, and openWorldHint false, but the description adds substantial behavioural context beyond them. It discloses the interaction classes reported, the geometric definitions used (CREDO's as Arpeggio implements them), and an important limitation: `polar` is a hydrogen-bond criterion without the donor angle because crystal structures carry no hydrogens, so no angle-checked hydrogen bond is claimed.

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 primary purpose and then adds necessary caveats, with no obvious filler. It is longer and denser than most definitions, but every sentence contributes to understanding the tool's scope or its geometric/chemical contract.

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 rich schema coverage, read-only annotations, and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers purpose, antigen-detection behaviour, interaction semantics, and the key limitation of the polar criterion without needing to duplicate return-value 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 description coverage is 100%, so the parameter definitions already carry the semantic load. The description adds conceptual context about antigen discovery and the `polar` interaction type, but does not give additional parameter-specific syntax, format, or edge-case guidance beyond what the schema provides.

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

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

States a specific verb ('Type') and resource ('ANTIBODY-ANTIGEN INTERFACE of a deposited complex'), and enumerates exactly what is reported: which residues touch, how close, and the interaction type. An agent can distinguish this from neighbouring antibody tools such as antibody_liabilities, antibody_isotype, or graft_antibody_cdrs without opening any schema.

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

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

The description gives clear context for use: a deposited complex is required, and the antigen is found rather than named, with the rule that chains lacking an immunoglobulin variable domain are treated as antigen. It does not explicitly name alternative tools or state when not to use this one, so it falls short of the top mark.

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 readOnly/openWorld/destructive annotations already covering safety, the description adds valuable provenance: it reads IMGT/GENE-DB per-label translations for every species and is graded against UniProtKB curated human constant chains. It does not discuss error modes or rate limits, but adds meaningful 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?

Front-loaded with the core purpose and well-organized into purpose, contrast, and provenance sentences. Slight redundancy repeats CH1/hinge/CH2/CH3 and the domain list, but overall efficient for the tool's 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?

Given the output schema, annotations, and full schema coverage, the description supplies what is missing: clear purpose, contrast with domain search, and data-source behavior. Nothing essential for an agent to invoke it correctly is absent.

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 defines protein, species, minIdentity, and record parameters. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 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: name the constant region of an antibody chain, identifying immunoglobulin gene/allele and IMGT domain positions. It explicitly distinguishes itself from a generic domain search, so an agent can tell it apart from scan_protein_domains-style 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?

Contrasts with domain search by explaining that this tool reports the isotype, not just a C1-set domain. Provides clear context for use, but does not name specific sibling tools 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?

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: hits are annotated with their IMGT region so CDR vs framework can be distinguished, and every motif is cited to a source. It does not discuss limits, performance, or failure modes, but the annotated baseline keeps the bar modest.

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

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

Two sentences with zero filler: purpose plus the enumerated checks up front, then the region-placement and citation behavior. Every clause carries information an agent can act on.

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

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

An output schema exists, so return-value explanation is not required, and the description covers what is scanned, the liability taxonomy, and the region/citation behavior. It could be more explicit that the input must be a variable-domain sequence for IMGT placement to be meaningful, which is the only notable gap.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the rules enum values and cdrOnly semantics. The description's enumeration of liability classes corroborates the rules enum and the IMGT-region framing explains why CDR filtering matters, but it adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('Scan') and resource ('antibody and TCR variable domains') and enumerates the exact liability classes it reports. An agent can distinguish this from neighbors like protein_properties, number_antibody, or antibody_molecule without opening any schema.

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

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

The domain restriction to antibody/TCR variable domains implies when the tool applies, but there is no explicit when-to-use versus alternatives and no stated prerequisites or exclusions. Usage is inferable rather than spelled out.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful behavioral detail: it computes MW, pI, pH-dependent net charge, extinction coefficient, and A280 under reduced and cystine-paired cysteine states, and it discloses the chain-termini handling and benchmark validation.

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 three dense sentences, front-loaded with the computed properties and format distinction. The final benchmark sentence is somewhat ancillary but supports trustworthiness, and every sentence contributes without excessive repetition.

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

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

An output schema exists, so return values need not be exhaustively described, and annotations cover safety and world scope. The description nonetheless supplies enough context about antibody assembly, Fab/IgG formats, cysteine treatment, and termini handling for correct invocation, leaving only sibling-choice guidance as a minor gap.

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

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

Schema coverage is 100%, so the schema already documents pH, heavy, light, format, _files, and _subject. The description adds meaning beyond the schema by clarifying that heavy and light chains are assembled as a molecule rather than concatenated, and by explaining the Fab versus IgG copy-number distinction in terms of assembled antibody structure.

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 resource and computed outputs: properties of an assembled antibody from heavy and light chains, including MW, pI, net charge, extinction coefficient, and A280 for Fab or IgG. It is clearly distinct from generic protein_properties because it specifies antibody assembly, but it does not explicitly name or compare against any sibling 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?

Usage is implied by the description: use it to compute molecular properties for an assembled Fab or IgG from separate heavy and light chains. The caveat that chains keep their own termini hints at correct versus incorrect usage, but there is no explicit when-to-use guidance or comparison with alternatives such as protein_properties or antibody_isotype.

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=false, destructiveHint=false and openWorldHint=false, but the description adds genuinely non-derivable behavior: the coordinate-space gate, the special coordinates_only basis recording, and the fact that it reports non-fitting features instead of trimming. It stops short of describing exactly how the open record is mutated or what the report looks like, so a 4 rather than 5.

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

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

Five sentences, front-loaded with the core action and then the refusal rules; each sentence carries substantive information rather than filler. It is slightly dense/long, but no sentence is redundant for a tool with this much gating logic.

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

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

An output schema exists so return values needn't be explained, and annotations cover the safety profile. For a 5-parameter tool with nested objects, the description supplies the decisive coordinate-space contract and overflow behavior, leaving nothing an agent needs in order to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description synthesizes the interplay the schema documents piecemeal: file/sequence disambiguation ('with several, this refuses and names them') and the conditional requirement logic for coordinates_only. It clarifies intent (avoid applying the wrong chromosome's intervals) beyond the raw field 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?

States a specific verb and resource ('Put the features from a GTF ... onto the open record') and immediately clarifies why the operation is needed ('a GTF carries no sequence, so this is how one reaches a molecule'). An agent can distinguish this from siblings like annotate_region or load_record without opening a schema.

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

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

Gives explicit proceed/refuse conditions: proceeds when both sides name the same genome build, refuses outright when they name different ones, and refuses when either is silent unless coordinates_only is passed. This is an unambiguous when-to-use rule plus the escape hatch, with no reliance on inference.

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

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

Beyond the read-only annotations, the description discloses important behavior: it returns edited bases, the edit range, and length change; it checks REF and refuses mismatch while naming both alleles; and it refuses symbolic and breakend alleles with reasons. These are valuable failure modes and validation semantics. It does not cover every edge case, but it adds substantial behavioral context beyond the structured annotations.

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

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

The description is three tightly written sentences. It front-loads the operation and return values, then adds the REF validation rule, then the symbolic/breakend refusal. Every sentence carries distinct, useful information with 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 output schema and the detailed input schema, the description covers purpose, core behavior, validation, and return values. Safety annotations already cover read-only status. The main gap is that it does not help the agent route between this tool and related siblings, but for calling the tool correctly it is largely complete.

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

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

Schema description coverage is 100%, so the parameter schemas already document each field, including offset, alt_index, and _subject. The description adds conceptual context about REF/ALT matching and assembly consistency but does not add parameter-level syntax or meaning beyond the schema. Per the rubric, the baseline is 3 when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Substitute one called ALT allele into a sequence' and returns the edited bases, edit range, and length change. This is clear enough for an agent to understand the operation. However, it does not explicitly distinguish the tool from related siblings such as read_variant_calls or score_variant_effect, so it falls short of a 5.

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

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

The description gives implied usage conditions: the REF allele must match the sequence, and symbolic or breakend alleles are refused. This tells an agent when the tool is applicable and when it will fail. It does not, however, name alternatives or contrast the tool with sibling tools, so it remains only implied 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 destructiveHint=false. The description adds genuine behavioral context beyond them: it discloses the auditing performed on concatenated tag+oligo products (junction homopolymer, reverse-complement 5' tetramer, synthesis length).

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 front-loaded sentences: the first states the conversion and output formats; the second states the audit scope. No filler, and the purpose precedes the 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?

Given an output schema, rich annotations, and 100% schema coverage, the description supplies the needed conceptual and audit context. It omits some minor operational details (e.g., that barcodes is required, or that primer is required with format=primer), but the schema handles those.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the adapter-vs-primer format, orientation, and optional spacer, but adds no syntax or constraints beyond the schema's own per-parameter 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 states a specific verb and resource ('Turn index sequences into the oligos a synthesiser makes') and distinguishes its scope from index-only checks by noting it audits problems visible only after tag and oligo are concatenated.

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

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

Usage is implied by the assembly purpose and the audit clause, but the description never explicitly says when to choose this over siblings like design_barcodes, audit_barcodes, or check_index_pool, nor does it state prerequisites or exclusions.

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

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds meaningful behavioral context: RBSs are designed against real upstream context, and the output includes sequence, layout, and per-gene achieved strength.

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 tightly written sentences front-load the core action and the key distinction from design_rbs. The parenthetical em-dash clause earns its place by explaining the context-aware design behavior, and there is no filler.

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

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

With 100% schema coverage, an output schema, and annotations covering safety, the description provides sufficient high-level purpose, behavior, and sibling differentiation. It does not need to restate parameter details or return values.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds conceptual framing around RBS context and target strength but does not provide additional syntax, defaults, or constraints beyond what the schema states.

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 ('Stack'), resource ('several CDSs into one contiguous operon'), and key differentiator (context-aware RBS design). It distinguishes this from design_rbs by explicitly noting that the RBS for gene 2 is not the isolated RBS design_rbs would produce.

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 clearly implies when to use this tool versus design_rbs by contrasting context-aware operon assembly with isolated RBS design. However, it does not explicitly state when-not to use it or name other assembly alternatives like golden_gate_assemble or gibson_assemble.

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 disclose readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered externally. The description usefully adds that the plan is DnaCauldron's spreadsheet shape and that it 'Emits the FINAL construct as a record', which clarifies the write behavior, but it says nothing about failure modes, partial simulation results, or side effects on library documents. Adequate with annotations in place.

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

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

Three sentences, front-loaded with the core action, then the multi-level mechanic, then the input shape. No filler. Slightly redundant with the schema's own description of the plan format, but tight overall.

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

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

Output schema exists, so return values need not be explained, and the 100%-covered schema handles parameters. The description supplies the conceptual model (dependency levels, products-feed-next-level) that an agent needs to invoke it correctly. Missing only explicit routing against single-level assembler siblings.

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%, including a detailed description of `plan` and `parts`, so the schema already carries parameter meaning. The description's restatement of the spreadsheet shape (`construct_name, part, part, …`) largely duplicates the schema, adding little beyond it. Baseline 3 applies.

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

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

States a specific verb and resource ('Run a MULTI-LEVEL assembly plan') and names the underlying object (DnaCauldron `AssemblyPlan`). The 'multi-level / dependency levels / level's products become parts for the next' framing cleanly separates it from single-step siblings like gibson_assemble, golden_gate_assemble and assemble_operon.

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 multi-level dependency description implies the scenario this tool is for, but there is no explicit when-to-use / when-not-to-use statement and no sibling named as an alternative. An agent can infer usage from the 'several assemblies arranged into dependency levels' wording, but must do the routing itself.

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

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

Annotations already declare readOnly/non-destructive/closed-world, so the safety profile is covered. The description adds genuine interpretive context beyond that: readings are taken with hydrogens implicit (the form the papers assume), and an alert flags a nuisance/reactive substructure rather than being a verdict on activity or toxicity. This is real behavioral value, though it omits any note on cost/runtime for a heavy multi-descriptor computation.

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 clause is well front-loaded, but the bulk is one very dense run-on sentence exhaustively listing every computed output — essentially return-value enumeration that the existing output schema already supplies. Much of that list does not earn its place for tool selection and 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?

An output schema exists, so return values need not be enumerated, yet the description still gives the input conventions (SMILES/molfile, one molecule per call, implicit hydrogens) and a crucial interpretation caveat about alerts. Complete enough for an agent to invoke correctly; the missing piece is explicit routing against sibling molecule tools.

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 including the rules and alert_sets defaults. The description contributes only marginal semantics, such as clarifying that the _paper rule ids are the papers' own readings where medchem departs from them, which is largely mirrored in the schema's own rule description. Baseline 3 is correct.

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?

Names a specific verb (assess) and resource (small molecule) and then enumerates the exact computation families: RDKit descriptors, medchem drug-likeness rules, structural-alert catalogs, formula/isotopes, QED, ESOL, SA, NP-likeness, Bemis–Murcko, BOILED-Egg. An agent can distinguish this deep single-molecule profiling tool from siblings like compare_molecules, cluster_molecules or screen_molecule_library.

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

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

Usage is implied by the scope — assess one molecule given as SMILES/molfile — but no explicit when-to-use or when-not-to-use framing is given, and no alternative (e.g. compare_molecules for pairs, screen_molecule_library for batches) is named. The 'one molecule; for an SDF pass one record' constraint lives in the schema, not 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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral content beyond that: it discloses the concrete outputs (minimum distance, error-correction guarantee, distance matrices, optional pruned subset), which is what the agent needs to know about the result.

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

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

Front-loads the key distinction (audit existing vs design new) before enumerating outputs. The em-dash chain is slightly dense and the closing sentence is somewhat decorative, but no sentence is wasted.

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

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

With an output schema present, return values needn't be spelled out, and annotations carry the safety profile. The description covers purpose, alternative, and the audit computations; it is complete enough for correct 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%, so the schema already documents metric, prune_to_errors, required_distance and the record params. The description gestures at pruning ('subset that survives pruning to a stricter error budget') but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (check/audit) and resource (an index set you already have), and explicitly separates itself from the design-a-new-one path. An agent can distinguish this from design_barcodes/design_free_codes without opening the schema.

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

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

Explicitly frames the use case: 'Check an index set you ALREADY have, rather than designing a new one,' and gives the scenario ('inherited from a kit or a previous experiment'). It names the alternative category rather than a specific sibling tool, so a 4 rather than 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 declare readOnlyHint, destructiveHint=false and openWorldHint=false, but the description goes well beyond safety: it discloses what is exempt from judging (partial ends, /pseudo CDS), the read-through extension behavior round a circular origin, whether an overrun hits another annotated CDS (fusion), and the fold-over-random-backbone comparison. This is unusually rich 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 front-loaded with the core check list and then the exceptions and read-through behavior. It is dense but nearly every clause adds information; a minor cost is its length and the trailing Biopython-parity validation claim, which is more marketing than actionable specification.

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

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

With an output schema present, return values need not be described, and annotations cover the safety profile. The description supplies the check semantics, exemptions, and read-through reporting that an agent needs to invoke this correctly, so nothing essential 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 schema fully documents genbank, _files and _subject. The description adds only the conceptual framing 'one or more GenBank maps' and does not clarify otherwise-undocumented parameter semantics, so the 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 states a specific verb (audit/check) and resource (annotated CDS of GenBank maps) and enumerates the exact faults it detects: frame that does not close, internal stop, invalid start codon, missing terminal stop, translation mismatch. This clearly distinguishes it from siblings like find_orfs, auto_annotate, and discover_annotation_contradictions.

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

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

Usage is implied by the audit framing and the exclusions (partial ends not judged, /pseudo CDS carries no flag), which help an agent know what the tool will and will not act on. However, there is no explicit 'use this when' guidance or naming of alternative tools (e.g. find_orfs, discover_annotation_contradictions), so the agent must infer when to prefer this over siblings.

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

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

Annotations give readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description adds useful context by saying it "emits an annotated record" whose annotations carry into a downstream map or export, explaining why the tool is not read-only. It does not mention permissions or limits, but the core behavioral consequence (a new annotated record rather than an in-place edit) is disclosed.

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 purpose and matching strategy; the second sentence efficiently covers the output behavior. The first sentence is dense and its parenthetical is heavy, but no sentence is wasted.

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 16-parameter, nested-schema tool with full schema coverage, annotations and an output schema, the description covers the essential purpose, the matching modes and the output record, so an agent can select and invoke it. It is only incomplete in that it gives no routing guidance against the many sibling annotation/search tools.

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

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

Schema coverage is 100%, so all 16 parameters are already documented, including mode, policy, and the protein-corpus thresholds. The description adds the conceptual framing of exact vs alignment matching and the site classes it recognizes, but no syntax or edge-case meaning beyond the schema, so baseline 3 applies.

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

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

The description gives a specific verb+resource (find and name known features such as vector parts, origins, resistance markers and tags) and immediately specifies the matching strategies (exact, local alignment, both) and special site classes (Cre/loxP, Gateway att). It is clearly more than a restatement of the name, but it never names a sibling (e.g. annotate_region, audit_cds_annotations) to sharpen the boundary.

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

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

The description explains what the tool does and the mode variants, which implies the annotation use case, but it never states when to reach for this over annotate_region or the various find_* siblings, nor any prerequisites or exclusions. Usage is left to inference from the field descriptions.

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 destructiveHint=false, so this is a safe, non-mutating computation. The description adds real behavioral context beyond that: it is table-weighted, it does not optimize, and it must be followed by optimize_sequence for gene-design objectives, plus each strategy's algorithmic basis.

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

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

Front-loads the core mapping and the non-optimization caveat, with no filler. Slightly redundant because the strategy enumeration largely duplicates the rich strategy enum descriptions in 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?

With an output schema present, return values need not be explained, and the description covers the strategy space, the non-optimization boundary and the follow-up tool. An agent has enough to call it correctly, though the host/table interaction is left to the schema.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents host, seed, table and strategy at length. The description largely restates the four strategies rather than adding format or interaction detail the schema lacks (e.g. how host interacts with table).

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 direction ('Protein → DNA: the coding sequence that would encode a protein') and immediately names the four strategies that define the tool's scope. It is clearly distinguishable from siblings like optimize_sequence or translate_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?

Adds a strong negative boundary ('It does NOT optimize: for restriction-site avoidance, a GC target or repeat removal, follow it with optimize_sequence'), which routes the agent to the right next tool. It lacks an explicit positive 'use this when' sentence, but the strategy breakdown implies the use cases well.

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 operation read-only, non-destructive, and not open-world. The description adds substantive behavioral context: it explains the probabilistic network model, how shared peptides are weighted, and that output consists of posterior probabilities. It does not discuss computational cost or caveats, but it goes well 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 dense sentences, front-loading the method and the output quantity before explaining the shared-peptide treatment. The parenthetical validation detail is useful but slightly expendable; overall it is efficient and well-structured.

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

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

Given an output schema exists, the description need not explain return values. It also benefits from complete schema coverage for the 15 parameters, which covers required inputs and defaults. The description supplies the conceptual model but could more explicitly point to required inputs like psms and database, though the schema handles that adequately.

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 fully documents all 15 parameters, including the roles of alpha, beta, gamma, and gridSearch. The tool description adds no further parameter-specific semantics beyond what is already in the schema, so the 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 states a specific method and output: Bayesian protein inference using Epifany, yielding posterior probabilities for proteins, indistinguishable groups, and peptide-spectrum matches. However, it does not explicitly distinguish this tool from the sibling infer_proteins, so an agent must infer the distinction from the method name.

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?

Use is implied by the Bayesian inference framing and the parameter details for grid search, but the description never states when to choose this over alternatives such as infer_proteins. There is no explicit when-to-use or 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 readOnly/non-destructive/closed-world, and the description adds real value beyond them: the local DB is built from every project record of the program's alphabet and E-values are computed against that database's own size, which changes how hits should be interpreted. It also states "nothing leaves the machine," a meaningful privacy/scope trait. Only minor gap is that it says nothing about result size or runtime for large projects.

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?

Four short sentences, front-loaded with the scope and database-construction constraint before the use case and the alternative. Every sentence carries distinct information, though the middle clause about database size and E-values is dense and could be tightened.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies everything else an agent needs to choose this over blast_search and understand the E-value basis of the 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 coverage is 100%, so the schema already documents program, region/feature, maxExpect, and the query/subject shapes; baseline is 3. The description reinforces the blastn=nucleotide / blastp=protein mapping but adds no syntax or semantics the schema does not already carry.

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 (search) and a tightly scoped resource (THIS PROJECT'S OWN records), plus the concrete scope constraints: the local database is built from every project record of the matching alphabet. It explicitly names the sibling it is not (blast_search for public databases), so an agent can distinguish the two without opening schemas.

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

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

Gives the positive trigger ("ask which of my constructs, reads or proteins carry this span") and the exclusion with an alternative ("for public databases use blast_search"). When-to-use and when-not-to-use are both explicit, and the local-vs-public boundary is the exact decision an agent faces here.

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 destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: 'The sequence LEAVES THE MACHINE' makes the external egress and data-disclosure consequence explicit, and it names the downstream artifacts (hits, tabular report, job id). It still omits anything on service limits, queuing, or how long remotely-run jobs take.

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

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

Three lean sentences with the purpose front-loaded, then the variant scope, then the downstream payoff, closing on the all-caps network warning. No padding or restated boilerplate; every clause carries 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?

An output schema exists, so return-value structure need not be re-explained, and annotations cover the read-only/open-world safety profile. The description supplies purpose, egress behavior and downstream artifacts, which is sufficient for a tool this complex with nested objects and 9 parameters. Missing only explicit sibling routing for the many other BLAST-like tools.

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 (email, region, feature, program, sequence, databases, parameters, plus the nested _subject/_files) carries its own documentation, so the schema does the heavy lifting. The description restates the program list but adds no syntax, format, or default meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Search a sequence against NCBI BLAST+ at EMBL-EBI'), enumerates the programs and databases covered, and describes the transformation ('turns an unnamed span into named homologues with E-values'). It is unambiguous what the tool does, but it never differentiates itself from blast-like siblings such as blast_project_sequences, delta_blast_smart, rps_blast_cdd, or ebi_align.

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?

Use is implied rather than directed: 'This is the similarity search a methods section cites' positions it as the canonical homolog search, and the note about handing the job id downstream hints at workflow placement. There is no explicit when-to-use/when-not guidance and no named alternative for more targeted BLAST variants in the sibling list.

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

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

Annotations already carry the safe-read profile (readOnlyHint/destructiveHint false, openWorldHint false), and the description adds substantial behavior beyond that: it refits a few hundred times, iterations is the run's whole cost, and per-reaction design avoids 9,400 refits. It also explains that a fixed model is refit per iteration so Cqs stay comparable.

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

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

Front-loaded with the core purpose and the differentiator against error propagation, and every sentence is substantive. It is dense and somewhat long, with a couple of explanatory clauses that could be trimmed, but nothing is padding.

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

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

With an output schema present, return values need no prose. The description covers method, scheme choice, model-refit semantics, cost, and the upstream provenance (qpcR 1.4.2 pcrboot), leaving nothing an agent needs to call it correctly unstated.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds conceptual meaning: why iterations maps to cost and quantile resolution, what boot vs jack actually resample, and the rationale for include_readouts being on. Most of this is echoed in the schema descriptions, so it adds value but not a full dimension above.

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 ('Resampling error bars on ONE reaction's Cq') and immediately scopes the statistical problem it solves ('how tightly the observations pin that model down'). An agent can distinguish this from call_cq (which just reads off a Cq) and propagate_uncertainty without opening any schema.

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

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

Gives clear context (per-reaction by design, boot vs jack semantics, when each scheme answers a different question) and implicitly rules out error-bar approaches that propagate a measured spread. It lacks an explicit named alternative or a 'do not use this for X' exclusion, so it stops short of 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds meaningful context beyond that: the default nuclease ('SpCas9 unless told otherwise'), the MANE/HGNC resolution chain, and the lane-level window-size limits ('Each lane refuses a window wider than it will read, and says so'). That last point is a useful behavioral disclosure.

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

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

The main purpose is front-loaded in the first clause, and every subsequent clause maps to a distinct output lane, so little is wasted. It is a dense run-on paragraph rather than structured bullets, which slightly hurts scannability, but the density is justified by the tool's breadth.

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

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

With an output schema present, return-value explanation is unnecessary, and the description still covers inputs, resolution precedence, defaults, and lane limits. For a 7-parameter, nested-schema tool it is close to complete, though it omits any note on cost, rate limits, or how the _subject/_files project context interacts with the browse.

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 descriptions are already unusually rich, documenting gene precedence, 1-based inclusive locus, nuclease default, and track options. The description largely restates this ('Give a gene symbol... or a locus, 1-based and inclusive', 'SpCas9 unless told otherwise') rather than adding new parameter meaning, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Read one window of a genome the way a genome browser shows it') and then enumerates the exact data lanes returned (cytogenetic bands, transcripts, protein residues, dbSNP 155 counts, ClinVar pathogenic calls, CRISPR sites). This level of specificity clearly distinguishes it from siblings like annotate_region or lookup_gene.

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

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

It explains the two input modes (gene symbol resolved through MANE Select then HGNC, or a locus) and states that gene takes precedence, which implies usage. However, it never names an alternative sibling (e.g. annotate_region, lookup_gene) or states when NOT to use this tool, so routing guidance is only implied.

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

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

The annotations declare readOnlyHint=true and openWorldHint=false, but the description explicitly says 'It WRITES A FILE' (a write side effect) and 'The sheet is fetched from Addgene each run' (external network interaction). Both statements contradict the annotations, making this a serious consistency failure.

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 action and is reasonably tight, though listing example drop-down values adds slight verbosity. Every sentence still carries useful information about behavior or validation.

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

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

An output schema exists, so return values need not be explained. The description covers key behaviors (fetching current sheet, rejecting and naming refused values, writing a file, not sending anything), but omits practical details such as the output file's location or format, which would be helpful for a file-writing 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 the schema already documents all four parameters thoroughly. The description adds minor examples of answer columns (purpose, plasmid type, etc.) but does not meaningfully extend the parameter semantics beyond what the schema provides, matching 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 states a specific verb and resource: 'Fill Addgene's own deposit spreadsheet from a record', and details the row content (one row per plasmid with name and sequence plus answers). This clearly distinguishes it from sibling submission builders like build_genbank_submission and build_ena_submission.

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

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

It gives clear context for use (depositing to Addgene from a record) and a useful workflow hint: 'run once without answers to read them from `columns`.' However, it does not explicitly state when to choose this tool over alternatives such as build_genbank_submission or build_ena_submission.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: output is 'pandas-compatible CSV', the report is composed of named artifacts, and the errors spreadsheet is characterized as the most useful output for a failed run. It does not spell out return structure, but an output schema exists.

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

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

Two sentences, front-loaded with the core action and then the wiring instruction; every clause carries information (report contents, output format, upstream inputs). It is dense but not padded. Minor density from the enumerated artifacts keeps it just short of ideal.

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 a rich 7-parameter schema at 100% coverage, existing annotations, and an output schema, the description supplies the missing cross-tool wiring and format notes an agent needs to call it correctly. Nothing critical is absent, though a brief note on ordering (assemble first, then build report) would make it fully self-contained.

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 by tying parameters to report semantics (the enzyme becomes the report's `enzymes` column and should be left empty for Gibson to avoid implying an enzyme exists) and by specifying the required shape of `products` (id, sequence, fragmentNames). This is meaning beyond the schema, though not exhaustive for every 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?

States a specific verb and resource ('Build DnaCauldron's assembly report from an assembly result') and enumerates exactly what the report contains: the per-construct summary table, the constructs and errors spreadsheets as pandas-compatible CSV, and the Outcome / Number of assemblies stats. It also names the upstream assembly nodes it consumes, so an agent can distinguish it from unrelated report/export 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 second sentence gives explicit wiring context: 'Wire golden_gate_assemble or gibson_assemble's products, errors and warnings outputs into it', which tells the agent when this tool is appropriate (after an assembly run) and which sibling outputs feed it. It stops short of stating exclusions (e.g. when a report is unnecessary), so it is clear context rather than full 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 declare `readOnlyHint=true` and `destructiveHint=false`, but the description explicitly says 'It WRITES FILES,' which is a filesystem write and contradicts the read-only claim. This is an annotation contradiction; despite otherwise useful validation detail, the contradiction forces a 1.

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 transformation and then details validation checks; every sentence contributes useful information. It is dense but not bloated for a 10-parameter, nested-object 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?

With an output schema present, the description needn't explain return values. It covers purpose, validation, side effects, and error reporting, though the annotation contradiction creates a misleading signal about the write side effect.

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 cross-parameter validation notes (unknown keys, missing mandatory qualifiers, double quotes, duplicate features, entry under 100 bp) that go beyond individual schema fields, but it largely repeats schema-provided meanings for study, description, mol_type, and organism.

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: turning a record into an ENA flat file (`.embl`) and manifest for Webin-CLI, with validation against ENA's own feature tables. It distinguishes itself from other build_* siblings by naming ENA, Webin-CLI, and the file types produced.

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

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

Gives clear context: this is for building an ENA Webin-CLI annotated-sequence submission, it writes files, and it sends nothing. It does not explicitly name an alternative sibling to use instead, but the ENA/Webin-CLI framing is sufficient to route correctly among the build_* tools.

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

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

Annotations only cover safety/openness; the description adds a great deal of behavior the agent could not otherwise know: retired feature keys are migrated to `regulatory`, unapproved qualifiers are dropped by name, unknown keys survive as `misc_feature` with the original name, and collection_date/geo_loc_name are validated against INSDC vocabularies before any file is written. It also discloses that files are written locally with no account, key, or upload, which is consistent with openWorldHint=false and destructiveHint=false.

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 deliverable and the 'not a GenBank export' caveat are correctly front-loaded, but the middle stretch (the 2014 feature-key retirement, the plasmid-map aside, the refusal/migration narrative) is dense flavor that does not directly help an agent select or invoke the tool. It is information-rich rather than wasteful, yet it is longer than the invocation decision requires.

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

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

An output schema exists, so return values need not be explained, and the annotations cover safety. What remains — required inputs, the mandatory date/location validation, the fact that nothing is uploaded and the template is the caller's responsibility — is all stated, leaving no material gap for a correct call.

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

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

Schema description coverage is 100% and the schema already documents mol_type, geo_loc_name, collection_date, topology and the `_subject` record selector in detail, so the baseline is 3. The description reinforces a few of these (mandatory-by-Date facts, source modifiers on the defline) but adds little syntax or format detail beyond what the schema states.

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 first sentence states a precise verb+resource+artifact: turn a record into the submission set `table2asn` consumes, specifically a `.fsa` with source modifiers plus a 5-column `.tbl`. It also explicitly rules out adjacent interpretations ('This is not a GenBank export'), so an agent can separate it from exporters and from the ENA/addgene deposit siblings without opening any schema.

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

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

It gives clear when-not guidance ('GenBank's submission pipeline takes neither a .gb nor a plain fasta') and defines the boundary of responsibility ('table2asn` stays yours to run'). It does not, however, name an alternative sibling such as build_ena_submission or build_addgene_deposit, so routing between deposit builders is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the methodological scope (distance through Bayesian MCMC under a strict clock and coalescent prior) and what the output carries (bootstrap/aLRT/aBayes support or clade posterior probabilities), though it omits any warning about the very different runtimes of ML/Bayesian versus distance methods.

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 purpose and tightly packed for a 49-parameter tool; the closing pipeline directive is short and actionable. The method/support enumeration mildly duplicates the schema enums, which is the only thing keeping it from a 5.

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

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

Given an output schema exists and the schema carries full parameter documentation, the description need not restate returns or parameter mechanics. It supplies the algorithmic scope and pipeline placement an agent needs to select the tool, leaving only runtime/cost trade-offs unstated.

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 49 parameters and 100% schema description coverage, every parameter is already fully documented in the schema, so the baseline of 3 applies. The description's mention of method families and support types maps onto schema enums rather than adding new syntax or constraint detail beyond them.

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

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

States a specific verb (build) and resource (phylogeny) and enumerates the algorithm families it can run (distance, parsimony, ML, Bayesian), which is far more than restating the name. An agent can immediately distinguish it from siblings like draw_tree, export_tree, transform_tree, or tree_statistics, which operate on an existing tree rather than inferring one.

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?

'Wire it downstream of align_sequences' gives a concrete pipeline precondition and points at the correct upstream sibling. It does not, however, name any explicit exclusions or alternatives (e.g. when to prefer draw_tree/compare_trees instead), so it stops short of full when/when-not routing.

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

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

Beyond the readOnly/openWorld annotations, the description discloses material behavior: results reproduce R exactly (uniroot's root at R's tolerance), an unreachable target is refused with R's own message, and the response carries a power curve around the answer plus the reproducing R call. The caveat that effect_size is 'a convention, not a measurement' is honest and useful.

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?

Purpose is front-loaded and sentences mostly earn their place, but the middle enumeration of the thirteen tests and their pwr effect-size mappings is dense and partially overlaps the test enum description. Slightly heavy, though not padded.

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

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

With an output schema present, return values needn't be explained, and the description still notes the curve and R call returned. Combined with full schema coverage and annotations, an agent has everything needed to select and call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning above the schema: solve_for's default resolves to the test's sample size (n/n2/N/v), and effect_size is flagged as a convention rather than a measured value. It adds framing without duplicating every field's syntax.

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+scope: 'Power and sample size for a planned experiment,' then delineates the two regimes (sizing a test vs. describing a fixed design). It enumerates thirteen tests across two families, which clearly scopes it apart from narrower siblings like calculate_rnaseq_power.

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

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

It states the operating rule plainly ('Leave ONE quantity out with solve_for and it is solved; everything else is given'), which tells the agent how to invoke it. It gives clear context for when the tool applies but names no explicit alternatives or exclusions (e.g., vs. calculate_rnaseq_power or estimate_effect_size).

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 establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful behavioral context: the RNASeqPower 1.52.0 method, a negative-binomial count model with Poisson sequencing noise and biological CV², and grid-return behavior, though auth/rate limits are not relevant.

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?

Four dense sentences, front-loaded with the purpose and then the key invocation rules and method. No filler; every clause carries statistical or usage 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 complex 11-parameter statistical tool with an output schema and full schema description coverage, the description covers the core computation and the solve-for mode. It leaves the _files/_subject record plumbing and sibling routing to the schema and other tools, which is a minor gap.

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

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

Schema coverage is 100%, so each parameter is already documented in detail. The description adds the cross-parameter rule for omitting one of n, cv, effect, alpha, or power and the vectorization behavior that the answer is the whole grid, which is useful meaning beyond the individual schema fields.

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 first sentence specifies the exact computation (sample size and power for a two-group RNA-seq comparison, one gene at a time) and names the statistical model, so the agent knows the domain. It does not explicitly name or contrast with the sibling calculate_power, so it is clear but not sibling-differentiating.

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

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

The description explains the invocation pattern — leave one of n, cv, effect, alpha or power out, or name it in `solve_for` — and notes that inputs are vectorized into a grid. It does not say when to choose this over calculate_power, estimate_effect_size, or plan_rnaseq_experiment, so alternative selection is left implicit.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely non-obvious behavior: that instrument calls are discarded, bases/positions/quality are re-derived from peaks, the returned read may be a DIFFERENT LENGTH than the file, and that this operation does not itself modify the read. This is meaningful behavioral disclosure beyond structured data.

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

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

Three tight sentences, front-loaded with the action, then the surprising behavioral note (different length), then the sibling relationship. Every sentence carries distinct information and none 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 non-trivial tool with an output schema (so return values needn't be explained), full annotation coverage, and 100% param documentation, the description supplies exactly the missing pieces: what it derives, the length caveat, and its relationship to the adopting sibling.

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 `table`, `_files`, `_subject`, and `document`. The description adds no parameter-level detail (e.g., how `table` affects scoring), so the baseline 3 applies.

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

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

States a specific verb+resource ('call the bases of a Sanger trace from the signal') and clarifies the mechanism (discarding instrument calls, deriving from peaks). It explicitly distinguishes itself from the sibling `adopt_trace_calls`, so an agent can tell the two apart without opening a schema.

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

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

Names the alternative (`adopt_trace_calls`) and states the division of labor: this tool ANSWERS the question while the sibling applies the answer onto the read. Clear routing context, though it gives no explicit exclusions or when-not guidance (e.g., versus `call_mixed_bases_from_trace`).

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