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

Since no annotations are provided, the description carries the full burden and performs well. It explicitly details a key behavioral trait: failed names are reported while successful structures are returned. It also explains the conditional use of 'cdxml' for ChemDraw editing.

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 tool definition is structured logically, starting with the core function, then providing limitations, and finally detailing parameters. Every section is tightly written and efficiently organized.

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

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

Given the complexity of handling batch processing, multiple formats, and custom rendering, the description is remarkably complete. It provides all the necessary context and constraints for an agent to invoke the tool correctly despite the sparse structured data.

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

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

Despite having 0% schema description coverage, the description provides high-value semantic context for every parameter. For instance, it explains the functional difference between 'abbreviate_groups' (consistency) and 'render_style' (use case for printing/slides), adding meaning far beyond the schema data.

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 purpose is highly specific: drawing multiple individual compounds as PNG/SVG files and panels. It clearly distinguishes itself from sibling tools by stating it is not suitable for single compounds (use generate_molecule), reaction schemes, or structural comparisons.

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 tool explicitly forbids certain use cases, detailing that it should not be used for single molecules, structural differences, or reaction schemes. It provides direct redirection to the correct alternative sibling tool for each specific scenario.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior beyond the signature: the calculation solves the exact charge balance, reports the textbook approximation alongside it, and explicitly flags when the approximation's assumptions fail rather than returning a silently wrong number. It does not state that the tool is a pure computation with no side effects, nor mention precision/rounding or how the two results are labelled in the response — with an output schema present, the omission of return-format detail is minor.

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

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

The definition is front-loaded: purpose first, then the disambiguation block, then a clean per-argument list. Every sentence carries information, though the metaphor-laden second paragraph ('the approximation has lost its assumptions') is slightly longer than needed to convey the same behavioral point.

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 13-parameter computational tool with no annotations, the description covers purpose, alternatives, the meaning of every parameter and the tool's output semantics, and an output schema exists so return values need not be explained. The only gap — which parameters apply to which topic — is partly addressed by the per-argument topic hints.

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 0%, so the description does real work: it defines every one of the 13 parameters, including physical units (mol/L, mL, g/mol) and the distinction between pka ('of the acid, or of the conjugate acid of a base') and pkb. It also scopes two parameters to specific topics — target_ph applies to buffer_recipe/ionisation, drug_type to ionisation. It does not say which parameters are required per topic, and it never warns that all numeric parameters default to 0, which is the main risk with 12 optional numerics.

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

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

The opening states a specific verb and resource — 'Calculate pH, buffer composition and buffer recipes' — and the topic enumeration names the exact cases solved. It explicitly distinguishes itself from generate_titration_curve and generate_species_distribution ('this one computes, those draw'), so an agent can route 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 an explicit 'Not this tool for' block naming the two sibling alternatives and the condition that selects each (drawing pH vs titrant volume, drawing species fractions over the whole pH range). It also tells the agent to 'Pick the topic' and what data to supply ('You supply the pKa values from the monograph or table'), giving both selection and prerequisite 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?

No annotations exist, so the description carries the full load — it discloses the algorithmic behavior (MCS computed, shared scaffold kept neutral for contrast) and that the result is a figure rather than prose, which is meaningful behavioral context. It stops short of stating failure behavior for unresolvable names or whether a file is written, which are the remaining gaps for an annotation-free tool.

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

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

Front-loaded with the core definition, then usage, then exclusions, then args — a rational order with clear sectioning. The conversational-trigger paragraph is slightly padded and repeats the ibuprofen/naproxen example already used earlier, costing a point.

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 the description covers scope, exclusions, and all three parameters. The only thin spot is edge-case behavior — what happens with fewer than 2 structures, more than 4, or an unresolvable name.

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 0%, so the description must compensate, and it does: structures accepts 2-4 English/IUPAC names or SMILES, labels are per-panel display names that are localizable, and title is an optional localizable heading. This adds real meaning beyond the bare schema types and closes the coverage gap.

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 ('Compare 2-4 molecules side by side') and explains the mechanism (maximum common substructure with non-shared parts highlighted), which tells the agent exactly what the output depicts. It also names the siblings it is not (generate_molecule, batch_generate), so it is distinguishable 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 explicit when-to-use triggers ('user wants to compare structures', 'study a drug class'), an explicit not-for clause with named alternatives for both exclusions, and even a conversational trigger word ('difference'). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does it well: same deck name updates rather than duplicates (front is the key), `deck_name` is ignored when `curated_deck_id` is set, `deliver` has three concrete modes, `reversed` produces one note/two cards, `cloze` changes what front/back mean, and 'Parent::Child' nests subdecks. These are non-obvious side effects an agent could not infer from 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?

Long but front-loaded and segmented: purpose first, then triggers, then the two fill paths, then card anatomy, then options, then per-argument notes. Every paragraph answers a distinct question an agent would otherwise have to guess at.

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 nested-card export tool with 5 params, the description covers card construction, proven card types, update semantics and delivery modes; the output schema relieves it of explaining return values. Minor gap: it doesn't say what happens if neither `cards` nor `curated_deck_id` is supplied, nor where the .apkg file is written.

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 0% at the top level, but the Args block documents all five parameters, including the enum-like values for `deliver` and `curated_deck_id` that the schema does not constrain. The card-side constraint (text plus at most ONE visual, with the shapes of structure/reaction/spectrum) supplies the nesting semantics the schema leaves implicit.

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 artifact: 'Export an Anki flashcard deck (.apkg) with rendered chemistry images.' It also clarifies the division of labour (tool renders images, the agent supplies card content), which no sibling tool does.

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

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

Explicitly names the triggering situations (flashcards, study deck, exam coming up, intent to learn) and routes between the two fill modes: own `cards` vs `curated_deck_id`. It also states an exclusion ('Never deliver via AnkiConnect unless asked') and names both curated deck IDs with their contents.

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

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

With no annotations supplied, the description carries the full disclosure burden and does substantial work: it names the embedding pipeline (ETKDGv3 + force-field optimization, explicit hydrogens), the side effect of opening a chat-panel viewer, and the file side effect (writes an SDF for modelling tools). What it omits is failure behavior for unparseable names/SMILES and where/how the SDF persists, 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?

Front-loaded with the core action and output, then usage triggers, then exclusions, then the critical input-format warning — a sensible priority order for an agent. The trailing Args block partly restates the prose, which is mild redundancy but justified given the zero description coverage 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?

For a two-parameter generation tool with an output schema present, the definition covers purpose, routing, input formats, and both render and file side effects, so an agent can call it correctly. It stops short of noting what happens on invalid input or whether the viewer/SDF artifact can be retrieved later.

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 0%, so the description must compensate, and it does: name_or_smiles is defined as an English/IUPAC name or SMILES string, and label as an optional localizable display name. The added warning to keep localized text out of name_or_smiles is genuine meaning beyond the schema, though it gives no SMILES syntax examples or validation rules.

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 ("Generate a 3D conformer") plus the concrete output form (interactive rotatable ball-and-stick model, SDF file). It explicitly distinguishes itself from generate_molecule for flat 2D drawings, so an agent can separate it from siblings without opening schemas.

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

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

Gives explicit positive triggers (questions about 3D structure, tetrahedral/planar geometry, conformation, spatial arrangement) and an explicit exclusion with a named alternative ("Not this tool for: a flat 2D structure drawing or a Fischer/Haworth projection — use generate_molecule"). This is the when/when-not/alternative pattern at full strength.

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

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

With no annotations at all, the description carries the full burden and does so: it states the hard substrate limits per family (e.g. SN2 needs methyl/primary/secondary halide plus one anionic nucleophile; SN1 needs tertiary/benzylic/allylic), that out-of-limit substrates return an error naming the reason, and that missing substrates or drawing failure fall back to the textbook example with substrates_drawn and fallback_reason set. It also discloses the stereocentre inversion outcome, which is genuine behavioral information rather than restated input.

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

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

Front-loaded with the core action, then organized into family limits, usage triggers, exclusions, and args — a structure an agent can scan. It is long-ish and mildly repetitive, since the exclusion of generate_reaction is stated twice (once as 'Not this tool for' and once as 'for anything else use generate_reaction'), but nearly every sentence carries information.

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

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

An output schema exists, so return-value structure need not be explained, yet the description still names the key result fields (substrates_drawn, fallback_reason). Combined with per-family preconditions, error behavior, and fallback behavior, nothing an agent needs in order to call this correctly for a three-parameter chemistry tool 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 0%, so the description must compensate, and it does for all three parameters: reaction_type's three values, substrates as names or SMILES with the per-family pairing (halide + nucleophile, or acid + alcohol), and current_step as 0 = overview of all steps versus 1-N = a specific step. This adds real meaning beyond the bare enum and array types.

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 line states a specific verb and resource — draw a reaction mechanism step by step with curved arrows using the user's substrates — and the three supported families (SN2, SN1, Fischer esterification) are enumerated. It explicitly names the sibling it is not (generate_reaction) and the condition that separates them (net equation without intermediates).

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 an explicit when-to-use trigger (user asks about these mechanisms or electron-flow arrows) and an explicit when-not (net educt → product is generate_reaction; unsupported mechanism types are generate_reaction). It even resolves the ambiguous case of 'why does …' questions, telling the agent that is the same request and to answer with arrows rather than prose.

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

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

With no annotations, the description carries the full burden and does disclose real side effects: it writes PNG/SVG files plus an interactive panel, and cdxml is a special-purpose extra. It also flags a genuine behavioral tradeoff (abbreviate_groups removes hover tooltips) and a mode that changes the return shape entirely (stereo_variants returns a pick list instead of a drawing, capped at 3). Gaps remain around where files are written, whether existing files are overwritten, and whether an unresolvable name errors or falls back — enough to keep it from a 5.

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

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

Well front-loaded: the core purpose and default status come first, then exclusions, then a per-argument glossary where each entry is one tight line. The only bloat is the exhaustive exclusion list, where a few entries (lookup for melting point/CAS/GHS) restate close variants of the same routing rule; trimming those would lose nothing.

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

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

For an 8-parameter tool with no annotations and 0% schema coverage, this is close to complete: purpose, alternatives, all argument semantics, and the key side effect (file writing plus panel) are covered, and the output schema means return values need not be described. The remaining shortfall is operational — no indication of output location, naming, or overwrite behavior, which matters for a tool whose main effect is writing files to disk.

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 0%, so the description must compensate entirely, and it does: every one of the 8 parameters is given meaning, allowed values, and defaults that the schema omits. The enum-like values for render_style (compact/presentation/grayscale), view (fischer/haworth/all_h), and formats (png/svg/cdxml) are spelled out, along with non-obvious guidance such as adding cdxml only for ChemDraw editing and using stereo_variants "only on request."

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 ("Draw one compound as a 2D structure") and immediately fixes scope with "the default for a single substance." It then distinguishes itself from the closest sibling (batch_generate) and from a dozen other tools by resource type, so an agent can route 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?

Provides an explicit negative-routing block ("Not this tool for: ... use X instead") covering individual vs. batch, comparison, reactions, data sheets, single named values, spectra, speciation, and 3D. It also affirmatively maps implicit user intents — a bare compound name, a "why does it behave this way" question, a Fischer/Haworth request — onto this tool, which is the rare case where intent-to-tool inference is documented rather than assumed.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the tool writes PNG/SVG (and optional CDXML) files, returns a panel with conditions rendered above and below the arrow, that CDXML preserves full structures while the PNG is abbreviated, and that a 'Apply coefficients' button exists in the panel. It does not state file locations, overwrite behavior, or any failure modes for unresolvable compound names, which keeps it short of a 5 for a file-writing tool.

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

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

Front-loaded with the one-line purpose, then a routing block, then a per-argument list — the structure matches how an agent reads it. The exclusion paragraph is dense but every clause routes to a distinct sibling, and the Args lines carry information the schema lacks. It is long, but for a 10-parameter tool with zero schema coverage the length is largely earned.

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 10-parameter generative tool with no annotations and no schema descriptions, the definition supplies purpose, routing, all parameter semantics, output artifacts, and the coefficients default-vs-explicit rule. An output schema exists, so return values need no further explanation, and nothing an agent needs to call this correctly 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 0%, so the description must compensate entirely, and it does: every one of the 10 parameters is documented with meaning beyond type — arrow values are explained with their symbols and retro's reactant/product convention, formats gets a default and a conditional rule ('Add cdxml only when edited in ChemDraw'), coefficients gets ordering and a strict 'set only when the user asks for a balanced equation' rule, render_style enumerates the four valid strings, and abbreviate_groups lists example labels.

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 ('Draw a reaction scheme from reactants, products and conditions') and immediately pins down the scope: arrow above/below conditions, three arrow types, PNG/SVG output. It also explicitly names the sibling tools it is not (generate_mechanism, generate_tlc, generate_molecule, batch_generate, compare_molecules), so an agent can route correctly 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 positive triggers ('Use it when explaining a reaction as well as for explicit drawing requests') and an explicit negative list with the substitute tool for each case: mechanisms with electron flow → generate_mechanism, TLC plates → generate_tlc, single compounds/properties → generate_molecule, independent structures → batch_generate, comparisons → compare_molecules. The when/when-not/alternative triad is fully covered.

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

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

No annotations are present, so the description carries the full burden; it discloses that it renders a plot with pKa values marked and that the caller must supply pKa values from its own knowledge. What is missing is the output medium (image vs. saved file) and any note about handing off to save_png, which matters given a save_png sibling.

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

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

Front-loaded with purpose, then when-to-use, then exclusions, then an Args block — a clean hierarchy with no filler sentences. Minor redundancy: the Args section largely restates parameter meaning already given in prose, and the "standard diagram" aside is decorative.

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 detail is not required, and the description covers purpose, selection criteria, alternatives, and all three parameters with their ordering constraints. Nothing an agent needs to invoke this 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 0%, and the description fully compensates: substance is a localizable display name, pka_values are per protolysis step and must be ascending, and labels are optional, most-protonated-first, with the hard constraint len(labels) = len(pka_values) + 1. None of that appears in the raw schema titles.

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 concrete verb and resource ("Draw the species distribution of an acid over pH") plus the underlying method (Henderson-Hasselbalch). It immediately distinguishes itself from titration-curve and pH-calculation siblings, so an agent can pick it without opening the schema.

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

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

Explicitly names the triggering user intents (which species dominates at a given pH, degree of ionization, absorption across membranes) and supplies a formal exclusion block routing titrant-volume/equivalence-point questions to generate_titration_curve and numeric pH/ionised-fraction questions to calculate_ph.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it 'draws exactly the peaks it is given; it predicts nothing', enforces axis conventions per type (IR inverted wavenumber, NMR ppm right-to-left, MS bars), and notes CDXML is unavailable for spectra. It does not describe where files are written or how they are returned, but the presence of an output schema covers the return contract.

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

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

Front-loaded with the core action, then usage guidance, then exclusions, then a structured 'Args' section — an agent can stop reading at any level. It runs long and repeats the axis-convention idea in the parenthetical, but each block adds distinct routing or parameter information rather than padding.

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

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

For a complex, 4-parameter generator with 0% schema coverage, the description fills every gap an agent needs: valid type values, unit conventions, optional-field semantics, defaults, and the boundary against predict_spectrum. Return values need not be explained because an output schema exists.

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 0%, so the description must compensate and it does: it lists all ten valid spectrum_type values (the schema has no enum), defines position units per type (cm⁻¹, nm, ppm, m/z), explains intensity as relative and negative only for ord/cd, defines width as half-width in x-units, and explains label annotation. It also covers title's dual role as plot title and filename and formats' default of both png and svg.

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 ('Draw a spectrum') and enumerates the exact spectrum types covered (IR, ¹H/¹³C NMR, MS, UV/Vis, Raman, NIR, fluorescence, ORD, CD) plus output formats. It explicitly distinguishes itself from generic chart/visualization tools and from the sibling generate_molecule, so an agent can identify it without opening the schema.

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

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

Gives explicit positive triggers, including the ambiguous case of a 'schematic' spectrum with no peak values, and instructs the agent to supply typical literature positions itself with concrete example values. It also names exclusions ('Not this tool for: working out WHICH bands to expect... use predict_spectrum') and a second alternative (generate_molecule), leaving nothing to inference.

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

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

No annotations are supplied, so the description carries the full burden, and it largely does: it discloses the underlying physics (exact charge balance), the derived annotations (equivalence points per protolysis step, buffer points at pH = pKa, optional indicator band) and the fact that it draws rather than solves-and-explains. It does not state the output artifact format or cost/runtime, but the output schema covers return values.

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 verb+resource, then behavior, then when/when-not, then args — a logical order an agent can skim. It runs long and the Args block partly restates parameter names, but with 0% schema coverage that repetition is justified rather than wasteful.

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 6-parameter plotting tool with an output schema, everything needed to call it correctly is present: units, pKa ordering, guidance that the caller must supply the chemistry data from its own knowledge, and clear boundaries against the two nearest 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 0% and all parameter titles are bare camel-case, so the Args block does real work: units for every numeric (mol/L, mL), ordering and cardinality constraint on pka_values (ascending, 1-3 values), substance as a localizable display name, and the shape of the optional indicator object ({"name", "ph_range": [low, high]}). Nothing is left to guess.

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: "Draw a titration curve: weak (or polyprotic) acid vs. strong base." It also names the computation basis (exact charge balance) and what is annotated on the plot, so the agent knows exactly what artifact this produces versus a numeric calculation.

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

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

Explicit when-to-use ("when the user asks about titrations, equivalence points, buffer regions or indicator choice") plus two explicit exclusions with the correct alternative named: generate_species_distribution for speciation, calculate_ph for a single numeric pH. Routing is unambiguous.

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

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

With no annotations, the description carries the full burden and does so: it states the tool predicts nothing, rejects out-of-range rf instead of silently clipping, defines plate orientation (start line at 0, front at 1), and notes CDXML is unavailable for plates. These are non-obvious behavioral constraints an agent could not infer elsewhere.

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 purpose sentence, then geometry, then exclusions, then Args — a clear structure with section labels. It is on the long side and the co-spot explanation is stated twice (narrative and the Not-this-tool block area), but almost every sentence adds information.

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

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

For a 5-parameter generation tool with an output schema (so return values need not be described) and no annotations, the definition covers geometry, validation rules, param meanings, and sibling boundaries. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0%, yet the Args section explains every parameter: the nested lane/spot structure with a worked JSON example, rf as a ratio with its valid range and rejection behavior, optional label and intensity (with the faint-spot effect), title's dual role as plot title and filename, and formats' allowed values and default. This fully compensates for the empty schema.

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

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

Opens with a specific verb+resource+output ('Draw a TLC plate sketch from Rf values as print-ready PNG/SVG files'), and explicitly distinguishes itself from generate_reaction and generate_spectrum. An agent can route this without opening the schema.

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

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

Gives a concrete trigger (user reports a TLC result, with a verbatim example utterance) and a separate 'Not this tool for' block naming the sibling tools to use instead. Both when-to-use and when-not-to-use are covered.

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

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

No annotations are supplied, so the description carries the burden — and it does disclose the response modality ('returns text', 'draws nothing') plus the upstream data sources behind each topic (PubChem, ChEBI, UniProt, KEGG), which tells the agent where facts come from and why coverage varies. It does not mention failure behavior for unknown compounds, caching, or rate limits, which keeps it out of the top band.

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-line purpose, then a scannable bulleted topic list, then exclusions — a logical order that lets an agent stop reading early once it has what it needs. It is slightly longer than necessary; the 'see the list above' pointer in Args and the repeated default restate information already given in the bullets.

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

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

For a two-parameter read tool with an output schema already documenting return values, the description covers everything else an agent needs: which topic yields which class of facts, the naming convention for input, and the boundaries against three overlapping sibling tools. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and does: every `topic` enum value is defined with the exact facts it returns, and the practical use case for at least two ('safety' for lab protocols, 'physical' for experimental values) is spelled out. The `name` parameter gains a hard constraint absent from the schema — English/IUPAC names only, with concrete contrastive examples ('Aspirin' not 'Acetylsalicylsäure').

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 — 'Fetch a specific fact or value about a compound as plain text' — and immediately clarifies the output modality. It explicitly separates itself from three siblings (generate_molecule for bare names, lookup_molecule_data for visual data sheets, predict_spectrum for derived spectra), so an agent can route correctly 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 both directions: a positive trigger ('when the request asks for a named piece of data') and three explicit exclusions each paired with the alternative tool to use instead. The default topic and the 'Not this tool for' block remove nearly all ambiguity about when to select it.

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

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

With no annotations to carry the burden, the description still discloses two non-obvious behavioral traits: internet access is required, and missing values are not evidence of absence (a real interpretation hazard for safety data). It also notes the molecule panel invokes it on the Data click. It does not cover latency, caching, or failure modes, which keeps it short of a 5.

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

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

Front-loads the payload description, then a labeled exclusion block, then an Args section — a clean decision-oriented structure. Every sentence carries information; the panel-trigger sentence is the only one that could arguably be trimmed for an agent audience.

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

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

For a single-parameter read-only lookup with no annotations and an output schema already documenting return values, the description supplies everything an agent needs: what is returned conceptually, when to pick it, which siblings to prefer instead, the accepted identifier formats, and the network dependency.

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 0% and the schema is a bare string with no description, so the description must define the argument entirely — and it does: "Pass English or IUPAC names, or SMILES" with an inline example ('Aspirin'). That is more than adequate for a single required parameter, though it does not discuss how ambiguous names are resolved.

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 ("Show a compound's data sheet") and enumerates what the sheet contains: structure, PubChem properties and GHS safety. The explicit "Not this tool for" block names the sibling tools (generate_molecule, lookup) that handle adjacent cases, so an agent can distinguish it 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 an affirmative use case ("a data sheet or facts available from those sources") plus two explicit exclusions with the alternative tool named for each: bare compound name with no data requested -> generate_molecule, single named value or physical constants/biological role/metabolic pathways -> lookup. Nothing about routing is left to inference.

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

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

With no annotations, the description carries the full burden and does: it discloses the method (curated table matched to structure, topological proton equivalence), the deliberate limitation (no ppm chemical shifts, deterministic rather than modeled), and the output ordering rule (high wavenumber first, centrality-ordered assignments). These are exactly the behavioral facts an agent needs to trust and interpret results.

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-sentence purpose, then structured bullets mapping topic to question, then constraints, then exclusions — a sensible order. A few phrases ('all of them exam material', 'honestly limited') are tone rather than information and could be trimmed without loss.

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?

Return values need not be explained since an output schema exists, and everything else an agent needs for a three-parameter prediction tool — topic routing, argument formats, determinism, known limitations, sibling routing — is present. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 0%, but the Args block compensates by documenting all three parameters: accepted name formats (English/IUPAC or SMILES) for structure, units (cm⁻¹) for wavenumber, and which topic consumes each. It stops just short of stating what happens if an inapplicable parameter is supplied (e.g. wavenumber with 'ir_bands'), leaving that edge case to inference.

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 line states a specific verb and resource ('say what a spectrum of this structure should show — or read a band') and the three topics are enumerated by name and output. The closing 'Not this tool for' paragraph explicitly separates it from generate_spectrum and lookup, so an agent can disambiguate 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?

Each topic carries its own use condition and required argument ('ir_bands' needs structure, 'assign_wavenumber' needs wavenumber in cm⁻¹). The alternatives — generate_spectrum for drawing from known peaks and lookup for measured data — are named with the condition that selects them, and the hand-off from band list to generate_spectrum is 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?

With no annotations provided, the description carries the behavioral burden and does disclose the invocation context, the clipboard/sandbox condition, accepted input format, and that it returns the written path. It does not mention overwrite behavior, permissions, or error handling for file writes, which are relevant gaps for a save operation.

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 warning not to call the tool is front-loaded, and the remaining sentences are short and purposeful. Every sentence adds either usage context or a relevant input/output detail without 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 the description need not explain return values in detail, and it already states that a path is returned. For a two-parameter internal helper it is largely complete, though filename semantics remain underspecified.

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 0%, so the description must compensate. It partially does by explaining that png_base64 is a base64 PNG with an optional data:image/png;base64, prefix, but it says nothing about the filename parameter's expected path, directory, extension, or overwrite semantics.

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

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

The description states a specific action (save a PNG), the expected input (base64 PNG), and the result (returns the written path). It also explicitly distinguishes this from the generate_* tools, which already write their own PNG and SVG files, so an agent can tell this is not the normal image-generation path.

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 an unusually explicit usage rule: never call this directly, because the panel's export button invokes it when sandbox clipboard access is blocked. It also names the relevant alternative behavior by noting that generate_* tools already write their files themselves.

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