Jean by Melad Labs

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 already state this is a non-readOnly, non-destructive, closed-world mutation. The description adds meaningful behavior beyond that: it appends rather than replaces, generates a caption from the drawing/tool/conclusion, numbers the figure, and preserves vector graphics.

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 sentences, front-loaded with the core action and then covering captioning, numbering, and vector preservation. It wastes no space and is appropriately sized for the operation.

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 and complete parameter documentation, return values and parameter details need not be in the description. The description covers the key action and notebook side effects, though it does not explain the _files/_subject context parameters.

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

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

Schema description coverage is 100%, so all six parameters are already documented. The description reinforces defaults for tab, caption, drawing, and entry_id, but adds little beyond what the schema already says.

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 and resource—"Put a drawing ... into the lab notebook as a numbered figure"—and lists examples (chart, gel, map). It clearly distinguishes this from drawing/export siblings by framing the action as appending to a notebook entry.

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

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

It makes the usage context clear: take an on-screen drawing and append it to the open entry or a named entry. It does not explicitly compare against alternatives such as export_map_svg or draw_gel, so it falls short of 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 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 this a safe read-only, closed-world operation, and the description goes beyond them by disclosing the underlying algorithm's parameterization: gap–gap and gap–residue columns are counted and a gap never matches, which materially affects results. The 4-row minimum is also surfaced, which is not enforced by the schema. Output format is covered by the output schema, so no deduction there.

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

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

Front-loaded with the core operation, then the model options, then the behavioral caveats and the wiring hint — a sensible order. It is dense and the 'gap–gap and gap–residue columns counted, a gap never matching' clause is terse to the point of being cryptic, but no sentence is redundant 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?

Given an output schema, full parameter descriptions, and read-only annotations, the description fills the remaining gaps: what the computation actually does, the row-count floor, alphabet support, and how to source the alignment. The generic `_files`/`_subject` plumbing is adequately documented in the schema itself, so nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by adding a constraint the schema omits: 'Needs 4 rows' gives a de facto minimum for `rows`, which has no minItems. It also restates model applicability (PID any alphabet, BLOSUM62/PAM250 protein, DNA nucleotides), which duplicates schema text, and says nothing extra about `components`.

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 technique and resource: principal component analysis over the pairwise similarity of alignment rows, with the similarity model choices spelled out. It does not name any sibling it competes with (e.g. build_tree, alignment_redundancy, genotype_pca), so differentiation is left to the reader's inference, but the operation itself is unambiguous.

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

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

There is real guidance on prerequisites ('Needs 4 rows') and on input wiring ('Wire alignedSequences from align_sequences'), which tells an agent how to obtain valid input. What is missing is when to prefer this over alternatives in a large sibling set — no statement of when PCA is the right analysis versus a tree, distance, or redundancy calculation, and no exclusion criteria.

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

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

Annotations already establish the safe read-only, closed-world profile, so the description is free to add real substance: the exact redundancy rule (highest percent identity to a row at least as long by ungapped residues), the Jalview gap-matching convention, and the filtering consequence. This is behavior an agent could not infer from annotations or 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 definition leads with the core verb and the redundancy rule, then adds the Jalview caveat and the wiring note. Three compact sentences with no filler, though the middle sentence is dense enough to require a careful read.

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 and 100% schema coverage across six parameters (including nested _files/_subject), the description only needs to carry the algorithm and data-flow. It does both, leaving only minor gaps such as return shape, which the output schema covers.

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 meaning beyond it by explaining that threshold is a percent identity cutoff at or above which a row is redundant and by grounding the comparison span (from/to) in the Jalview shorter-row comparison. The wiring hint for `rows` connects the parameter to a producer tool.

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?

Opens with a specific verb and resource ('Find the rows of an alignment that repeat another') and immediately defines what redundancy means here, so an agent can tell it apart from alignment_agreement or alignment_pca by concept. It stops short of naming a sibling tool it is not, which is what would earn 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?

Provides a concrete data-flow instruction ('Wire `alignedSequences` from align_sequences') and the downstream intent ('filtering keeps the longest representative of each near-identical group'), which implies when to reach for it. However, there is no explicit when-not guidance or comparison to the other alignment tools 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 declare this as a safe, read-only, non-destructive, non-open-world operation. The description adds useful context that the window, filters, and record cap match the pileup, and mentions downstream hand-offs, but it does not surface refusal conditions or sampling behavior in the description itself — those live only in the 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?

Two sentences, front-loaded with the purpose, with no obvious filler. The second sentence uses somewhat opaque jargon ('hand-offs') but remains brief.

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 read-only tool with nine parameters, full schema coverage, and an output schema, the description is reasonably complete: it identifies the resource, the returned data categories, and the pileup-consistency behavior. The main missing pieces, such as refusal when multiple alignments exist and filtering/sampling semantics, are covered by 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 all nine parameters are already documented in detail. The tool description only alludes generally to window, filters, and record cap; it does not add parameter meaning beyond what the schema provides.

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

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

The description clearly states a specific verb and resource: read one window of a BAM or SAM, returning reads, depth, and pair/library information. It is understandable without opening the schema, though it does not explicitly distinguish itself from nearby alignment-related siblings such as map_reads or browse_region.

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 window/pileup framing and the hand-off note about wiring `reads` into an alignment or screen. However, no explicit when-to-use, when-not-to-use, or named alternative tools are provided, so the agent must infer appropriate contexts.

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 that this is a safe, non-destructive, closed-world read operation. The description adds substantial unannotated behavior: Needleman-Wunsch with free end gaps, the IUPAC substitution matrix, SeqTrace parity, and deterministic alignment identical to the trace editor.

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 key action and output are front-loaded in the first sentence. The remaining sentences add useful algorithm and default-reference context without padding.

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

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

For an alignment tool with a fully described schema and an output schema, the description covers purpose, algorithm, determinism, and the important `reference` default. No essential invocation detail appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents `read`, `reference`, `_files`, and `_subject`. The description's note about leaving `reference` unset largely repeats the schema's own explanation, adding no new syntax, constraints, or examples beyond the structured 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 description gives a specific verb and resource: pairwise-align ONE sequencing read against a reference, producing two gapped rows. The emphasis on ONE read and pairwise alignment distinguishes it from broader siblings such as align_sequences or compare_reads_to_reference.

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 implies the use case is grading a read against a reference and explains the default behavior when `reference` is unset. However, it does not explicitly name when to choose this over siblings like align_sequences, compare_reads_to_reference, or verify_read, nor does it state exclusions.

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

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

Annotations already declare readOnlyHint and destructiveHint=false, yet the description still adds high-value non-obvious behavior: poapy's own default is LOCAL but this tool opens on global, and 'naming the wrong one is not an error the engine can raise — BLOSUM62 reads A, C, G and T as alanine...' which flags a silent-corruption mode. It also explains the gap_open vs gap_extend asymmetry ('an extension harsher than the opening makes the aligner prefer many short gaps to one long indel') and marks which parameters are ignored by which engine.

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 one fact that matters (two engines, neither a fallback), then engine-by-engine detail. For 17 parameters the length is defensible, though the embedded asides about biotite porting 'byte-for-byte' and Clustal/MUSCLE lineage are more flavor than triage value.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Given the tool's complexity, the description does the remaining work: it disambiguates all four enum-bearing parameters (engine, guide_tree, align_matrix, score_matrix), warns about the silent wrong-matrix case, and routes input assembly. Only the required:[] surface (_subject + include_subject as an alternative to sequences) is left implicit.

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

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

Schema coverage is 100%, so the schema baseline is 3; the description earns above that by supplying the conceptual frame the schema lacks — the two engines answer different questions, engine-scoped parameters are inert outside their engine, and the align_matrix/score_matrix split (alignment scoring vs quality-report scoring) is spelled out. It stops short of saying what the sequences parameter requires (it is not marked required anywhere) or how _subject/include_subject interact with sequences.

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

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

The opening sentence names a specific verb and resource ('Multiple-sequence alignment over several sequences') and immediately frames the two-engine split, which is the tool's real identity. It distinguishes the two internal modes decisively but never names the sibling it competes with (align_read for pairwise, ebi_align for remote MSA), so the agent must infer sibling boundaries itself.

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?

Engine selection guidance is unusually explicit: 'what a pile of reads over one locus wants' versus 'what a FAMILY of homologous genes wants, and what a reader coming from Clustal or MUSCLE expects' — plus the warning that neither is a fallback for the other. It also tells the agent how to feed inputs ('wire many upstream record/sequence outputs into sequences, or name library documents'). What's missing is any statement of when to prefer this over ebi_align or align_read, and no prerequisites/minimum sequence count.

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?

Adds substantial context beyond the readOnly/non-destructive annotations: only `plate` yields verdicts and classifications, leaving expected_tm unset yields an honest absence rather than a guess, and the `extremum` auto default is flagged as a trap because upstream assumes a rising signal while solution-phase melts fall, returning a plausible-looking wrong Tm. The cross-engine note that replicate spread travels with all three because it describes readings, not method, is exactly the kind of behavior an agent cannot infer from 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?

Front-loaded and dense with intent—each clause about the engines carries decision-relevant content. It is written as one very long multi-clause paragraph with heavy backticking and emphasis, which is harder to scan than the information warrants, but there is little outright 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 29 parameters, an output schema, and full schema descriptions, the prose covers what cannot be derived: engine selection semantics, the verdict-classification contract, and the one dangerous default. What's missing is only the inter-tool context—how this differs from melt_profile or melting_temperature—which leaves a small but real gap for an agent choosing among 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 coverage is 100%, so the baseline is 3; the description earns above that by explaining how engine choice partitions the 29 parameters and by giving the rationale behind expected_tm and the auto-extremum hazard. The remaining engine-specific knobs (peak windows, bilinear seeds, window_ceiling) carry their meaning in the schema already, so the description adds framing rather than new parameter meaning.

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

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

The description opens with a specific verb+resource ('Melt curves to melting temperature') and then distinguishes its three internal engines by what each uniquely answers (verdicts / sub-grid Tm / peak areas). It never names or contrasts with the sibling tools that overlap this space (melting_temperature, melt_profile, call_cq), so an agent cannot tell from this text alone when to reach for this tool rather than those.

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?

Clear routing guidance among the three engines, including the explicit statement that none is a fallback for another, and the note that expected_tm is what converts peaks into verdicts. Still no guidance about when this tool applies versus sibling Tm/curve analyses, which is the more consequential selection decision.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safe read-only profile is clear. The description adds valuable context beyond annotations: it explains the scoring algorithm (log-odds against length-matched clusters), the threshold used, and that output includes the assigned class and median structure, which helps an agent understand the operation's behavior.

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

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

The description is front-loaded with the core action and stays within three sentences. The final sentence about being graded against the real SCALOP benchmark is somewhat extraneous for tool selection but does not bloat the description excessively.

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

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

Given that an output schema exists and annotations cover safety, the description provides enough context: it states the protein scope, lists which CDRs are classified, and notes that H3 is excluded. It could mention prerequisite numbering steps, but for a read-only classification tool the current detail 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 schema already documents all six parameters, including enums for scheme, definition, and species. The description adds only that H3 has no canonical classes, which lightly clarifies the classification scope but does not add parameter syntax or format details beyond the schema.

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

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

The description uses a specific verb and resource: 'Assign each CDR of an antibody heavy, kappa or lambda variable domain to its canonical structure class.' It explicitly names the CDR types covered and excludes H3, making the scope unambiguous and distinguishable from sibling tools like number_antibody or antibody_liabilities.

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 but gives no guidance on when to use it versus alternatives such as number_antibody (which may be a prerequisite) or graft_antibody_cdrs. There is no mention of when-not to use it or what inputs must already be prepared.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine analytical context (one count per reference allele vs one count per unique expressed sequence, the abYsis 1% cut default, the human naive B-cell provenance), but says nothing about cost, runtime, sequence-size limits, or how multiple variable domains in one input are handled.

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, followed by the two distribution modes and the default cut. The closing sentence about being 'graded against independent pandas counts' is validation metadata rather than task guidance, so it is the one sentence that does not clearly earn its place for an agent.

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 description covers the analytical scope, the two counting universes, and the rarity threshold. Combined with complete schema descriptions for 7 nested parameters, this is nearly sufficient for correct invocation, missing only routing guidance against sibling antibody 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; the description goes slightly beyond it by explaining what the two `distribution` values actually count over and by tying `rare_below` to abYsis's 0.01 unusual-residue convention. It does not clarify `germline_species` vs `species` interplay, but the added meaning is real.

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

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

The description names a specific resource (per-residue frequencies of an antibody variable domain at IMGT positions) and a specific verb-equivalent (count/compare to a rarity cut). It is clearly distinct from numbering or liability tools, though it never names a sibling (e.g. number_antibody, antibody_liabilities) to reinforce that separation.

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 through the two distribution modes: germline (IMGT V/J alleles) vs repertoire (bundled human OAS subset), which tells an agent what each mode means but not when to prefer one. There is no explicit when-to-use, when-not-to-use, or alternative-tool 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?

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 readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuine behavioural context beyond that: it discloses the three junction-level audits (homopolymer across the splice, 5' tetramer recurring as reverse complement, synthesis length overrun), which tells the agent what the output will flag.

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, purpose front-loaded, with the audit behaviour following as supporting detail. The second sentence is dense with em-dashes but every clause carries information; no filler or 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?

With an output schema present, return values need no explanation, and annotations cover safety. The description covers both operating modes and the audit outputs; only the interaction between format=primer and the required primer argument is left to the schema, which handles it explicitly.

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 including the nested _subject and _files is already documented. The description reinforces a few of them (adapter arms, primer, orientation, spacer) but adds no syntax, defaults, or constraints beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb and resource: it turns index sequences into synthesised oligos, spliced between adapter arms or onto a PCR primer. It also implicitly separates itself from index-only checks ('no check of the index alone can see'), which distinguishes it from siblings like audit_barcodes, though no sibling is named outright.

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

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

Usage is implied rather than stated: you bring index sequences and get oligos back, with two formats (adapter/primer) described. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as audit_barcodes, check_index_pool, or design_oligo_plate_order, which an agent must infer.

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

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

Beyond the annotations, the description discloses important behavior: arcs and inserts are routed to the same homology assembler as the single-insert tool, insert-to-gap assignment is determined by the homology graph rather than guessed, and no homology arms are designed. It also explains the refusal condition when insert ends do not match the arcs.

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 remains compact for a complex operation. Each sentence contributes either mechanism, routing behavior, or a failure condition, with no redundant restatement.

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

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

Given the presence of annotations, a complete input schema, and an output schema, the description provides enough mechanism and constraint information for correct invocation. It does not need to explain return values or repeat parameter documentation.

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

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

Schema coverage is 100%, so the parameter descriptions already carry the main semantics. The description adds conceptual context about multi-site assembly and automatic insert assignment, but it does not add parameter-specific detail beyond what the schema provides.

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

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

The description states a specific verb and resource: open one circular backbone at several sites and place several inserts in one step. It explicitly contrasts the approach with the single-insert tool, so an agent can distinguish it from related assembly tools.

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

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

It clearly frames the relevant scenario: a complete digest at multiple sites creates matching arcs and gaps that must be filled by the inserts. It also states a key constraint, namely that insert ends must meet the arcs or the assembler will refuse, but it does not explicitly enumerate when to choose this over named alternatives.

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

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

Annotations 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 readOnlyHint and destructiveHint=false, so the safety profile is covered; the description adds real behavioral context beyond them — readings are taken with hydrogens implicit, and structural alerts flag nuisance/reactive substructures rather than activity or toxicity. It does not mention cost, runtime, or failure behavior for invalid structures, which keeps it short of a 5.

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

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

The verb and resource are front-loaded, which is good, but the first sentence is an extremely long enumeration that largely restates the output schema. The two trailing sentences (hydrogen-implicit convention, alert-vs-toxicity caveat) are the highest-value lines and carry disproportionate weight.

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 need not explain return values, and it covers the input assumption (one molecule, implicit hydrogens) and a key interpretive caveat. What remains thin is guidance on single-molecule assessment versus comparison/screening workflows, the one thing an agent still has to guess.

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 rules, alert_sets, _subject and _files. The description only reinforces the molecule input format (SMILES or molfile) and the hydrogen-implicit assumption; it adds nothing about the semantics of selecting rule ids or empty alert_sets 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?

States a specific verb and resource ('Assess a small molecule given as SMILES or a molfile') and then enumerates the computed outputs (descriptors, drug-likeness rules, structural alerts, QED, ESOL, SAS, scaffold, BOILED-Egg, per-atom contributions), which makes its scope unmistakable. It never names a sibling, so an agent must infer that this is single-molecule characterization rather than comparison or library screening.

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

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

Usage is only implied by the breadth of the described report; there is no explicit 'use this when…' statement and no pointer to siblings such as compare_molecules, screen_molecule_library or cluster_molecules. The closing note that an alert is not a verdict on activity or toxicity is useful interpretation guidance, but it is about reading results, not about when to select the tool.

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

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

Annotations already declare this as a non-destructive, closed-world read-only operation, so the safety profile is clear. The description adds meaningful behavioral context: it reports minimum pairwise distance, guaranteed error correction, full distance matrices, and optionally the surviving subset after pruning. It does not discuss performance or computational cost, but that is not essential for this read-only audit.

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

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

The description is two sentences and front-loads the key distinction: check an existing set rather than design a new one. Every clause adds useful information about the audit outputs or the optional pruning behavior, with 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?

Given the presence of an output schema, the description does not need to enumerate return fields, and it still summarizes the main outputs. It also provides the key usage context and distinguishes the tool from its design siblings. Nothing critical is missing for an agent to decide when and how to call it.

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

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

Schema description coverage is 100%, so the input schema already explains barcodes, metric, required_distance, prune_to_errors, _subject, and _files in detail. The description adds conceptual framing around auditing an inherited set and pruning to a stricter error budget, but it does not map those ideas to specific parameter names or add syntax beyond the schema. Baseline 3 is appropriate 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 uses a specific verb, 'Check,' applied to a clearly defined resource: an existing index set. It immediately distinguishes the task from designing a new set by naming the alternative and explaining that this is for sets inherited from kits or previous experiments. The listed outputs (minimum distance, error correction, distance matrices, pruning subset) make the purpose unambiguous.

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

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

It explicitly says to use this tool when you already have an index set rather than designing a new one, which routes the agent away from design_barcodes/design_free_codes. The inherited-kit/previous-experiment framing gives a concrete usage context. No important when-not guidance is missing.

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 only say readOnlyHint=false and destructiveHint=false; the description adds the essential behavioural fact that this is a writer ('Emits an annotated record') whose output is consumed downstream by a map or export. It stops short of describing what happens to pre-existing features beyond pointing at the emitted record, but the mutation semantics are made explicit rather than left to the hint.

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, both load-bearing: the first scopes what is found and how, the second states the output effect. The long first sentence is dense but front-loaded with the core action rather than preamble.

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 16 parameters, a nested _subject object and an output schema, the description only needs to carry purpose plus the mutation semantics, and it does both. It leaves the mode/policy/filter interplay entirely to the schema, which is acceptable here, and nothing an agent needs to call it is missing.

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

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

Schema description coverage is 100%, so mode, policy, libraries and every protein-corpus knob are already documented in the schema. The description restates the exact/alignment/both distinction but adds no syntax, defaults or interaction detail beyond what the schema carries — 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?

Names a specific verb and resource ('Find and name known features on the subject') and enumerates the exact feature classes it recognises — vector parts, origins, resistance markers, tags, Cre/loxP and Gateway att sites. The three matching strategies and the either-strand/across-origin scope separate it cleanly from siblings like scan_motif_sites, find_orfs or annotate_region 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?

The description implies usage context through the feature classes and the exact/alignment/both modes, but never states when to reach for this tool versus a sibling such as annotate_region or find_restriction_sites, and gives no exclusions or prerequisites. An agent can infer the fit but must reason it 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 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description still adds real substance: the database is built from every project record of the program's alphabet, so E-values are computed against that local database size, and nothing leaves the machine. That statistical caveat is exactly the kind of context annotations cannot convey, though return shape is left entirely 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?

Three sentences, front-loaded with the verb and the scope, then the use case, then the alternative. No filler and nothing repeated from structured fields.

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

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

For a 7-parameter nested tool with an output schema, the description covers the things an agent cannot infer: local-vs-public routing, what populates the local database, and how E-values are affected. Return values are correctly left to the output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining that the program choice determines which records form the database ('of the program's alphabet'), tying blastn/blastp to search behavior rather than just declaring an enum, and it clarifies the fallback to the open record's region when no query sequence is wired in.

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) plus the exact resource and scope: this project's own records, on this machine, with blastn or blastp. It explicitly contrasts itself with blast_search, so an agent can pick it over that sibling 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?

Gives a concrete use case ('ask which of my constructs, reads or proteins carry this span') and an explicit exclusion plus alternative ('for public databases use blast_search'). The when-not condition is stated, not inferred.

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), and the description adds genuinely new behavioral context: the query is submitted to a third party and the sequence leaves the local machine, plus the tool emits hits, a tabular report and a job id for downstream use. It stops short of describing asynchronous job lifecycle, expected queue/runtime, or that a contact email is mandatory — the latter only surfaces in the 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?

Three sentences, front-loaded with the action and service, then outcome, then the uppercase data-egress warning in the position where it will be read. No sentence is filler and nothing is buried.

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 and annotations covering safety, the description need not explain return values, and it still signals the returned artifacts. What remains unstated — async job polling, timeouts, and the fact that a contact email is effectively required — is a modest omission for a remote submission 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%, including per-parameter notes on program alphabet derivation, region/feature coupling, database defaults and the free-form `parameters` passthrough, so the schema carries the semantics. The description adds only the parenthetical program list, which duplicates the enum, and does not explain the empty-sequence/region fallback beyond what the schema already 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?

States a specific verb and resource — 'Search a sequence against NCBI BLAST+ at EMBL-EBI' — and enumerates the five programs and the target databases (ENA, UniProtKB, PDB, vector-screening sets). It is clearly distinct from local/project search tools because it names a remote service, but it never explicitly contrasts itself with the many BLAST-family siblings (ebi_align, blast_project_sequences, delta_blast_smart, rps_blast_smart, rpstblastn_smart), leaving that routing to 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?

Implied usage is clear (turn an unnamed span into named homologues for a methods section), and 'The sequence LEAVES THE MACHINE' is a real decision signal about external submission. However, there is no explicit when-not guidance and no alternative named, which is a notable gap given roughly a dozen alignment/BLAST siblings that could be selected instead.

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.