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

Beyond the annotations, the description discloses that the source is unchanged, output goes to a new absolute directory, placement is bounded and can fail on collision/unsupported geometry, before/after exports and audit are produced, and no complete mechanism validation is promised. This gives an agent a clear behavioral model of a write-producing 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?

The description is dense but front-loaded: the main action appears first, and every subsequent sentence adds a distinct constraint or caveat. There is no filler or repetition of 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 complex 8-parameter tool with no output schema, it covers the new-copy semantics, failure conditions, review requirement, and output artifacts. The main gaps are the unmentioned optional rendering parameters and the absence of an explicit statement of what the tool returns (e.g., audit location or export paths).

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

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

With 0% schema description coverage, the description must document parameters. It explains the symbols array structure, output_dir, and hints at expected_source_token, but it leaves span, pixels, clearance, and line_width unexplained; their meanings must be guessed from names. Clearance is only obliquely referenced by 'bounded outward placement'.

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 names a specific action and resource ('Add native symbols to a NEW copy') and restricts the payload to explicit {key, kind, atom_id} requests. It also contrasts the operation with chemical edits and radical-state edits, which separates it from related sibling tools like chemdraw_edit_document or chemdraw_annotate_document.

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 a clear prerequisite ('Inspect current IDs/token first') and tells the agent this works on a copy, requires a new absolute output directory, and needs visual/chemical review. It does not explicitly name alternatives or state when not to use the tool, but the 'not a chemical edit' wording provides an implicit exclusion.

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

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

The description goes beyond the annotations by explicitly stating 'Source is not edited,' which is important given readOnlyHint is false. It also discloses that support is limited to 'supported drawings' and 'supported single molecules,' and reveals the recovery-snapshot side effect. This is meaningful 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 only three sentences and every sentence contributes: the first states the core output, the second explains how to use the returned token, and the third adds the analogue-edit context and the non-destructive guarantee. It is dense with domain jargon but contains 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?

There is no output schema, so the description reasonably enumerates the returned data: molecule IDs, bounds, text, arrows, and a top-level source_token. It also provides downstream usage context. However, it never explains what 'supported drawings' means, how object IDs are obtained, or the structure of the recovery snapshot, leaving notable gaps for an agent.

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

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

The schema has one required parameter, document_id, with 0% schema description coverage. The description does not mention document_id at all, nor does it explain how the document is identified or any constraints on it. Because coverage is low and the description fails to compensate, this dimension is weak.

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 action: 'Export a recovery snapshot and return molecule IDs, bounds, text, arrows and a top-level source_token for supported drawings.' This is more specific than the tool name and identifies concrete outputs. It does not explicitly distinguish itself from siblings like chemdraw_inspect_document or chemdraw_export, so it stops short of a 5.

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

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

It gives some downstream usage guidance: 'Use that token and explicit object IDs for scope grids' and mentions using the same token for analogue edits. However, it never says when to choose this tool over sibling tools such as inspect_document or export, and it does not state exclusions or when-not-to-use conditions.

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, so the description carries the behavioral disclosure burden. It does so thoroughly: source document is untouched, a new copy is created, existing molecules/symbols are retained, native errors are not retried, visual review is required, and no collision-free or native moving-attachment guarantee is promised. This 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 dense and front-loaded with the core purpose, followed by essential mechanics and caveats. It is long, and some parts could be clearer as structured bullets, but every sentence carries useful information and there is no filler. For a tool with six parameters and complex arrow semantics, this length is justified.

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

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

This is a complex tool with no output schema, yet the description adequately covers inputs, arrow construction rules, rejection cases, outputs (CDXML/SVG/PNG before/after, recipe, audit), safety behavior, and required follow-up review. The only notable gap is expected_source_token semantics, but overall an agent has enough to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It richly explains the arrows parameter structure, including source kinds, target kinds, offsets, controls, fishhook_side, and chemical-intent caveats. However, it does not explain expected_source_token at all, and pixels and line_width are entirely unmentioned. The description covers the hardest parameter well but leaves other parameters underexplained.

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

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

The description opens with a specific verb and resource: 'Add native full or fishhook electron-flow curves to a NEW copy.' This clearly distinguishes the tool from siblings like chemdraw_edit_document, chemdraw_add_symbols, or chemdraw_draw_structures by specifying the operation, the artifact being modified, and the non-destructive copy behavior.

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

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

The description provides clear usage context: inspect annotations first, add a symbol before annotating if needed, use atom/bond sources but not atom-label or positive-charge donors, and expect visual review afterward. It does not explicitly name alternative sibling tools or state when not to use it, but the preconditions and limitations are strong enough for an agent to decide when this tool applies.

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 meaningful behavioral context beyond the annotations: the tool creates a NEW copy, preserves the source, saves a selection audit, and rejects stale/modified proposals. These are important side effects and constraints that the minimal annotations (readOnly=false, destructive=false) do not reveal.

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 dense, purposeful sentences with no filler. The core purpose is front-loaded, followed by constraints and side effects, and finishes with a useful disambiguation from chemical mechanisms.

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?

Provides enough operational context: required freshness, explicit selection, new-copy behavior, source preservation, and audit saving. It does not describe return values, which is notable given no output schema, but the invocation constraints are sufficiently complete for a competent agent.

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

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

With 0% schema description coverage, the description must compensate for missing parameter documentation. It conceptually maps candidate_id to the selected route, document_id to the source document, output_dir to the new copy, and report to the audit. However, it does not explain the report shape, pixels, or formatting expectations, leaving meaningful gaps.

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

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

States a specific action ('Validate and render') on a precise resource ('one explicitly selected suggested route in a NEW native copy'). The final sentence disambiguates from chemical-mechanism tools by clarifying it selects a geometric path. This clearly differentiates it from sibling tools like chemdraw_suggest_routes.

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?

Clearly implies when to use it: after a route is explicitly suggested, and only with a fresh unmodified snapshot. It also flags when the tool will reject input via 'Rejects stale snapshots or modified proposals'. However, it does not explicitly name sibling alternatives or state conditions for when another tool should be used 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 only declare readOnlyHint=false and destructiveHint=false, which are minimal. The description adds meaningful behavioral context: it creates a copy (so the original is presumably untouched), it does not normalize coordinates or reposition charges, and cleanup is separate. These are important side-effects and limitations beyond what annotations convey, though it does not address return values or side effects like saving or versioning.

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

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

The description is extremely concise: three short sentences, with the primary purpose front-loaded. It adds only necessary exclusions (coordinates, charges, cleanup) without fluff. Every sentence earns its place, and the structure is clear and scannable.

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 mutating tool with no output schema and no parameter descriptions, the description is incomplete. It lacks any explanation of what 'preset' options exist, what document_id refers to, or what the tool returns (e.g., the new copy's ID). While it covers the operation's scope, it leaves crucial invocation details undefined, especially given the flexible preset parameter.

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%, meaning the schema has no parameter descriptions. The description mentions neither 'document_id' nor 'preset', and does not hint at what 'preset' accepts (enum or object). With two parameters and one being complex (enum/object), the description fails to provide any semantic help. This is a severe 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?

The description clearly states the tool's purpose: 'Create a styled copy with consistent explicit fonts/strokes.' It identifies the resource (a copy) and the action (applying style), and distinguishes itself by noting what it does NOT do (normalize coordinates, reposition charges, or clean up). This differentiates it from sibling tools like chemdraw_clean or chemdraw_apply_route, though it could be more explicit about the 'styled copy' concept.

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 implicit usage guidance: it mentions 'Cleanup is a separate explicit action,' implying you should not expect cleanup here, and that coordinates/charges are not normalized, suggesting other tools handle those. However, it does not explicitly name alternative tools or state when to choose this over siblings. The guidance is contextual but not explicit enough to be a 4.

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

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

Goes far beyond the sparse annotations (readOnlyHint=false, destructiveHint=false), disclosing that private copies are created and closed, errors stop later items without retry or closure of uncertain documents, failures are per-item, and outputs need human review. This is exceptionally transparent about side effects and edge-case 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 long but information-dense, with no filler. It is front-loaded with the core purpose, then systematically covers output, constraints, copy behavior, error handling, requirements, and caveats. Every sentence earns its place.

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

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

For a complex batch operation with no output schema and minimal annotation support, the description covers most needed context: supported inputs, outputs, audit artifacts, error policy, and limitations. The missing 'pixels' semantics and lack of explicit return-value description keep it just short of 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 0%, so the description must compensate. It defines the items object structure precisely with key/source/formats, and clarifies output_dir as a new absolute output directory. However, the 'pixels' parameter is not mentioned at all, leaving a semantic 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: 'Sequential native batch export of explicit supported CDXML files.' It clearly signals batch operation, distinguishes itself from the singular sibling chemdraw_export, and enumerates the output contract (CDXML/SVG/PNG plus requested PDF/CDX).

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

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

Provides clear when-to-use constraints: supported CDXML files, required chemistry extra, flat drawings plus a specific annotation subset, and rejection of unknown annotations. It also states what the tool does not do ('No style/layout/chemistry edits'), though it does not explicitly name an alternative sibling for single-file export.

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

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses meaningful behavioral constraints: every fragment must be assigned exactly once, existing curves require curve_id plus explicit source/target {kind,id}, and the operation does not change manual dragging behavior. This is substantial non-obvious context.

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

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

Three sentences, front-loaded with the core purpose, followed by the most important structural and behavioral details. No filler or repetition of schema 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 read-only tool with no output schema, the description covers purpose, required ownership invariants, curve constraints, and a return hint. The only notable gap is that 'source-token-bound ownership' is left undefined, which may leave the exact return contract slightly ambiguous.

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

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

With 0% schema description coverage, the description compensates well by explaining the owners structure and curve requirements. It does not elaborate on document_id, but that parameter is self-evident from its name and integer type; the main semantic gaps are filled.

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

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

The description opens with a specific verb-resource pair ('Snapshot a native document and build explicit sidecar ownership') and immediately states the output shape: owner objects with key, fragment_ids, and caption_ids. This clearly distinguishes it from sibling tools like chemdraw_move_owned or chemdraw_build_scope_job, which target different operations.

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 intended use is implied: call this when you need to produce a sidecar ownership snapshot of a native document. However, it never explicitly states when to prefer this over alternatives or what conditions rule it out, leaving sibling selection partly to inference.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses that originals are untouched (consistent with destructiveHint=false), performs cleanup and checks, and stops without retry on native uncertainty. It does not mention permissions or error details, but covers key 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 a single dense paragraph that front-loads the main purpose and packs many details efficiently. It is not overly verbose, though it could be more structured with separate sentences for distinct aspects. It earns its place without much redundancy.

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

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

Given the tool's complexity (9 parameters, no output schema, no param descriptions), the description covers many aspects but misses specifics on layout, pixels, preset, and exact output delivery. It also does not clarify the 'expanded path' vs 'connected-only' input distinction fully. It is adequate but not comprehensive.

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 explains the structure of reactants/products and conditions, but leaves layout, pixels, preset, and scaffold_smiles semantics vague. For instance, 'pixels' and 'preset' are not described beyond defaults, and the expanded/connected-only distinction is not fully defined.

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

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

The description clearly states the tool creates a native reaction with explicit reactant/product records and conditions, and mentions constraints (1..3 each). It distinguishes from siblings like chemdraw_build_reaction_series by focusing on a single reaction, though it does not name alternatives explicitly.

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 provides guidance on input types (expanded vs connected-only) and what it does not do (reaction prediction). However, it does not explicitly compare with sibling tools or state when to prefer this over others, leaving some usage decisions to inference.

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

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

Annotations are all false (not read-only, not open world, not destructive), so the description carries the burden of behavioral disclosure. It discloses meaningful limits: no product inference, no balance certificate, support restricted to water/halides and bounded salts, and separate verification of native chemistry and layout. This goes well beyond the raw annotation fields and gives an agent a realistic picture of what the tool will and will not do. No contradiction with readOnlyHint=false, since 'Build' implies a write 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 description is two dense sentences with no filler, and the primary action and key constraint ('1 through 3 explicitly supplied reaction rows') are front-loaded. The jargon ('bounded salts', 'native chemistry and measured layout verified separately') is compact but meaningful, so nothing feels wasted. Slightly dense readability keeps it from a 5.

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

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

With 5 parameters, no output schema, and no per-parameter descriptions, the description explains the most complex input (steps and participants) and sets expectations about limits, which is valuable. However, it says nothing about layout, pixels, preset, or output_dir semantics beyond what their names imply, leaving the optional parameters underspecified. Adequate for the required inputs, but incomplete for fully informed 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%, so the description must compensate. It does clarify the steps array structure (step_id, reactants/products, optional above/below conditions) and participant fields (compound_id, label, smiles, optional positive coefficient), adding real meaning to the opaque schema. Yet layout, pixels, preset, and output_dir receive no explanatory attention, so the compensation is partial.

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 ('Build') with a clear resource ('1 through 3 explicitly supplied reaction rows on ONE editable ChemDraw page'), and the series scope differentiates it from the sibling chemdraw_build_reaction. It also states what the tool does not do (no product inference or balance certificate), removing ambiguity about its role. The resource and constraints are precise enough for an agent to know when this tool applies.

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

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

The description implies usage for explicitly supplied multi-row reaction series (1-3 rows) on a single page, and the 'No product inference' note signals it is not for route design or inference. However, it never names sibling alternatives such as chemdraw_build_reaction or chemdraw_build_scope_job, nor states explicit when-to-use/when-not-to-use conditions. The guidance is only implicit.

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

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

The description goes beyond annotations by disclosing meaningful behaviors: source drawings are left unchanged, no experimental outcomes are inferred, only a single physical page is supported, and overflow fails without shrinking molecules. This is valuable behavioral context not present in the schema or 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?

Three dense sentences with no wasted words. The main action and deliverables are front-loaded, and each subsequent clause adds a distinct constraint or behavior that earns its place.

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

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

The description is rich in high-level purpose and constraints, which is helpful given the weak schema and absent output schema. However, it leaves the structure of the `job` object ambiguous and does not explain `output_dir` or what the tool returns, so an agent cannot fully construct the invocation from the description alone.

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 carry parameter meaning. It lists job content components ('selected candidates, conserved scaffold, true category rows, headings'), but does not map them to the `job` object's keys, and the required `output_dir` parameter is never explained. The description provides partial semantics only partially compensates for the schema's silence.

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

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

The description names a specific verb ('Build'), resource ('scope job'), and key scope qualifier ('explicitly approved', 'in NEW native documents'), followed by concrete deliverables. This clearly distinguishes it from planning, decorating, or editing tools even without naming 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 phrase 'explicitly approved' implies this should be used after a planning/approval stage, and 'NEW native documents' implies creation rather than mutation of existing files. However, it never explicitly names alternatives such as chemdraw_plan_scope_job or states when not to use this 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?

The annotations already declare destructiveHint=true, and readOnlyHint=false, indicating this tool modifies data. The description adds that it 'changes depiction and can alter orientation', which is useful behavioral context beyond the annotations. However, it doesn't elaborate on the extent of changes, reversibility, or any side effects beyond orientation. It adds some value but not deeply.

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 succinct, with two short sentences. The key action is front-loaded, and the caution about depiction and orientation is stated briefly. No wasted words, though the 'after a recovery export' clause adds context without verbosity.

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

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

Given the tool's mutating nature, lack of output schema, and sparse schema coverage, the description is insufficient. It doesn't explain what the outcome will be (e.g., no confirmation, no mention of return values), nor does it detail the prerequisites or side effects. For a destructive operation with only 2 parameters, an agent might need to know more to call it correctly, such as whether document_id must be a working document, or the effect on the original file.

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

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

The schema description coverage is 0%, so the description must compensate for parameter documentation. It mentions 'specified molecule or whole document', which partially explains 'molecule_index' and 'document_id', but it doesn't explain the exact meaning of each parameter, the range of molecule_index, or the effect of null. The description is too high-level to guide correct parameter use.

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

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

The description clearly states the action ('Run native Clean Up Structure'), the target ('specified molecule or whole document'), and the context ('after a recovery export'). While it doesn't explicitly name alternative sibling tools, the verb 'clean' is distinctive enough among the siblings, and the mention of 'recovery export' gives a specific use case.

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 phrase 'after a recovery export' gives a temporal context, implying it should be used following a recovery export operation. However, it doesn't explicitly state when NOT to use it or point to any alternative tools for similar tasks, such as chemdraw_apply_style or chemdraw_polish_document. The guidance is implicit rather than explicit.

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

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

Annotations already indicate destructiveHint=true, so the description's emphasis on 'back up' adds context that the operation includes a backup step, which is beneficial. However, it doesn't explain the behavior of refusal in detail (e.g., what happens if you try to close a non-working document), and it doesn't mention any side effects like unsaved changes or locks. With destructiveHint true, the description should have explained that it saves changes as part of the backup, but it's adjacent.

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

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

The description is extremely concise, with one sentence that front-loads the main action ('Back up and close') and then states the constraint. It is well-structured and easy to parse, with no fluff.

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

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

Given the tool has only 1 parameterable, no output schema, and complex annotations (destructive), the description is moderately complete. It covers the core action and a key constraint, but it lacks details on how to handle the refusal, what the response looks like, and whether any confirmation is needed. With destructiveHint true, more information about the backup process or rollback would be warranted.

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 does not explain the document_id parameter beyond its type and requirement, but the description's mention of 'document opened by this server session' implies that document_id must refer to such a document. However, it doesn't explain how to find the correct ID (e.g., via list_documents), which is a gap. But for a single parameter, the description partially clarifies the semantics.

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

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

The description clearly states that the tool backs up and closes a document opened by the current server session, and that it refuses other documents. This is specific about the action and scope, but it doesn't explicitly distinguish it from sibling tools that might also close documents (though none seem to close). It is clear and actionable.

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 that it should be used for documents opened by this server session and not for others, but it doesn't explicitly say when to use it versus alternatives, nor does it mention prerequisites like the document being currently open. There is no mention of when not to use it beyond the refusal, which is a constraint rather than a usage guideline.

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, openWorldHint false, destructiveHint false, so no contradiction. However, the description does not disclose what happens on invalid CDXML, whether existing documents are overwritten, what output/return is provided, or any side effects beyond creating a document. For a creation tool with no output schema, this is a significant transparency gap.

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 no filler. Every clause earns its place: the action, the input format, the output type, and the critical constraint about no name resolver or chemistry invention.

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 one-parameter tool with no output schema and no annotations beyond default flags, the description should cover what happens after creation, error behavior, and any prerequisites. It says the caller supplies validated structures but not what the tool returns or how the agent will know it succeeded. The tool name and siblings suggest a document-management workflow, but the description leaves the success/return semantics 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 0% and there is only one required parameter, cdxml. The description identifies cdxml as the input format (CDXML) and says it must be validated chemical structures, which adds some meaning beyond the bare parameter name. However, it does not specify format details, size limits, or accepted variations.

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 (create) and object (editable native document from CDXML) and a key constraint (caller supplies validated structures; no name resolver or chemistry invention). It is clear what the tool does, though it does not explicitly contrast with siblings by 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?

The description implicitly tells the agent when to use it: when the caller already has validated CDXML and wants an editable native document, and explicitly tells when not to use it (when name resolution or chemistry invention is needed). It lacks an explicit mention of alternatives but the constraint serves as a usage guide.

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

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

Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. The description aligns by stating it 'writes' and 'does not publish or install anything'. It adds constraints about no embedded fonts, proprietary artwork, code, or local paths, and mentions content hashing, which goes beyond the annotations. However, it does not clarify overwrite behavior or error conditions.

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-loading the core action and then adding constraints. It is efficient with no wasted words, and the key purpose is stated first. The structure is easy to scan and understand.

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 create operation with 6 parameters, nested objects, and no output schema, the description lacks crucial details. It does not explain what 'preset' contains, how 'version' is used, what 'output_path' should point to, or how settings and references interplay. It partially covers settings and references but leaves major gaps for an agent to correctly invoke the 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It does explain 'settings' sections (grid/reaction/symbols) and 'references' format (names/hashes/descriptions), but completely omits name, version, preset, and output_path semantics. This leaves most parameters underspecified for an agent.

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 ('write') and resource ('new portable versioned numerical style JSON with content hash'). It also lists key aspects like settings sections and reference format, and explicitly distinguishes from publishing/installing. This differentiates it from siblings like import_style or apply_style, though it doesn't name a specific sibling.

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 it is for creating a new style file but does not provide explicit when-to-use guidance or name alternatives. It only notes what it does NOT do (publish/install), which hints at usage boundaries but doesn't give clear direction on when to choose this tool over others like chemdraw_import_style or chemdraw_apply_style.

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 are all default-false (readOnlyHint: false, destructiveHint: false), so the description carries the full burden, and it delivers extensively. It discloses that the operation writes to a NEW copy with source preservation, that 'uncertain native writes stop without retry' (fail-fast behavior), that output is native editable CDXML/SVG/PNG with a layout audit, and that human visual review is still required. This level of failure-mode and side-effect disclosure is exemplary.

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

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

Four dense sentences carrying distinct payloads: core action, group invariant, label/non-behavior, and output/failure semantics. The core action is front-loaded and every sentence earns its place. The density is high enough that an agent must parse carefully, but nothing is redundant and the organization parallels how the tool will actually be used (inspect → decorate → verify).

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

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

Given the tool's complexity (7 params, a nested groups structure, no output schema, all-false annotations), the description is unusually complete. It documents the required invariant (exclusive ownership, nonoverlapping top-to-bottom bands), label constraints (empty allowed, nonempty needs measured free space), and failure behavior. The only notable gap is the absence of any description of the layout audit's return format, which matters since there is no output schema to fall back on.

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 most parameters: 'optional native rounded shadow frame' covers frame, 'dotted group dividers' covers separators, 'New absolute output directory only' covers output_dir, and 'groups {label,fragment_ids,caption_ids} must own every source fragment and caption once' gives the groups parameter real meaning. Two parameters (pixels, document_id) receive no description-level semantics, and expected_source_token is only referenced obliquely via 'Inspect current IDs/source token first', so compensation is strong but not complete.

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: 'Decorate an existing flat scope in a NEW copy' with concrete outcomes (rounded shadow frame, dotted group dividers). The phrase 'No automatic chemical classification or molecule reordering' draws a boundary that helps separate it from analysis/build siblings. It does not, however, name any sibling explicitly, and with 40 sibling tools (build_scope_job, grid_document, polish_document) some ambiguity remains about where decoration ends and other visual-editing tools begin.

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 preconditions ('Inspect current IDs/source token first') and constraints ('New absolute output directory only'), which imply when the tool is appropriate. It also signals what the tool will NOT do ('No automatic chemical classification or molecule reordering'), a weak when-not boundary. However, it never names an alternative tool or states explicit conditions for choosing a sibling instead, leaving usage routing to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that it checks 'Mac installation, live connection and optional chemistry validator' and that it does not edit documents. It does not disclose what the output looks like or what 'optional' means in practice, but for a zero-parameter diagnostic tool the added context is adequate.

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

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

A single sentence that front-loads the action ('Check'), names the three checked areas, and explicitly excludes document editing. Every word earns its place; there is no fluff or repetition of the tool name.

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

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

For a zero-parameter, read-only diagnostic tool with no output schema, the description is largely complete: it states what is checked and what is not done. The only minor gap is not describing the return format or how the 'optional chemistry validator' is triggered, but given the tool's simplicity and annotation coverage, this is a small omission.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. The description still clarifies the tool's scope (installation, connection, validator) which is the only meaningful semantic content an agent needs. Baseline 4 for zero-parameter tools 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 ('Check') and resource ('Mac installation, live connection and optional chemistry validator') and explicitly notes it does not edit documents. It is clear enough to distinguish from the many sibling tools that perform document edits or build operations, though it does not name a specific sibling alternative.

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 this is a diagnostic/health-check tool to run before other operations, and the 'without editing documents' phrase signals it is safe to use in read-only contexts. However, it does not explicitly state when to use it versus alternatives or when not to use it, leaving the agent to infer its role from the sibling names.

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

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

The description discloses many behavioral traits beyond the minimal annotations: RDKit coordinate seeding, native ChemDraw import and Clean Up Structure, identity checks after import/cleanup, grid measurement after native save, new absolute output directory, editable/vector/PNG preview and audit, final document staying open, originals untouched, and stopping without retry on native uncertainty. No contradiction with annotations 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?

The description is dense but every sentence contributes operational or constraint information. It is front-loaded with the primary purpose, followed by relevant processing details and caveats. While not brief, the length is justified by the complexity of the tool and there is no obvious 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?

For a complex tool with no output schema, the description covers the main workflow, constraints, output artifacts, failure behavior, and review caveats. It does not explicitly describe the return value or audit contents, but it provides enough operational detail for an agent to invoke the tool and interpret a successful result.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It clearly explains structures (explicit 1..24 compound_id,label,smiles records), scaffold_smiles (explicit common core, rigid alignment, no inference), and output_dir (new absolute output directory). However, layout, pixels, preset, columns, and charge_style are not described, leaving several parameters without semantic context beyond their names and defaults.

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

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

The description opens with a specific verb and resource: 'Create a native ChemDraw figure from 1..24 explicit {compound_id,label,smiles} records,' making the tool's core action clear. It does not explicitly contrast itself with siblings such as chemdraw_create_document or chemdraw_build_reaction, though the stated focus on explicit SMILES records implicitly differentiates it.

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

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

The description provides several situational constraints: connected nonradical structures only, no name lookup, no yields, and scaffold_smiles behavior. It does not explicitly say when to use this tool instead of a sibling or mention alternatives for name lookup or yields, so the usage guidance is implied rather than explicit.

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 signal a non-read-only, non-destructive operation. The description adds material behavioral context: it operates on a copy, leaves the existing source untouched, preserves coordinates, performs no cleanup, verifies chemistry/labels/coordinates after export, and requires visual review.

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

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

The description is dense but front-loaded with the core purpose and contains no filler. All sentences add necessary detail, though a slightly more structured layout would improve scannability.

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

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

For a tool with no output schema, it explains outputs (before/after exports, chemical diff), verification behavior, and operational constraints. It relies on 'Analyze first' and source token naming, but does not state how to obtain document_id/source_token or what the exact return payload is; still, it is largely complete for calling the 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?

With 0% schema description coverage, the description carries the burden. It documents the operations object structure (atom/bond kinds, required fields like hydrogens and order) and the caption rule (explicit replace/retain/null-remove). It does not spell out document_id/output_dir/pixels, but those are inferable from names.

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 ('Make an edited COPY'), resource ('one molecule'), and outputs ('native before/after exports and chemical diff'). The copy semantics and diff output clearly distinguish it from sibling editing tools, even without naming them.

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

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

Gives an explicit prerequisite ('Analyze first') and enumerates supported vs unsupported operations ('Supports neutral main-group atom/H changes... no insertions/deletions...'), which tells an agent when to use this tool and when not. It does not name alternative tools, but the exclusions are actionable.

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

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

Adds meaningful behavioral context beyond the basic annotations: refusing overwrites, offline resvg rasterization for PNG, and explicit failure without rasterizer fallback. The annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false, so this extra disclosure is valuable. No contradiction detected.

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 dense sentences pack in the tool's identity, a crucial overwrite behavior, PNG-specific processing details, a hard prerequisite, and a failure mode. Every sentence carries distinct information with zero 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?

For a moderate-complexity export tool with no output schema, the description covers the prerequisites, key options, and failure behavior sufficiently for an agent to invoke it correctly. The only notable gap is that it does not describe what a successful call returns, but this is not essential for making the 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 0%, so the description must compensate. It explains 'pixels controls longest side' and implies path is a file whose parent must exist. However, document_id is left to inference, and format is covered only by the enum. It adds some semantics but does not fully compensate for 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?

The description states a clear verb+resource: export a document through actual ChemDraw, and adds a key behavioral constraint ('refusing overwrites'). It does not explicitly differentiate from the sibling chemdraw_batch_export, which is the natural alternative, leaving some ambiguity about scope.

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

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

There is no explicit when-to-use guidance or named alternatives. The description does provide useful prerequisites ('Output parent must exist') and a limitation ('Unsupported SVG resources fail explicitly'), but it never tells an agent when to pick this tool over batch_export or another sibling.

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?

Since annotations are all false (readOnlyHint=false, openWorldHint=false, destructiveHint=false), the description carries the full burden of behavioral disclosure. It reveals several important behaviors: '0% remains visible; missing yield omitted,' 'overflow fails, never shrinks individual molecules,' 'Columns auto-fit if omitted,' and 'Multi-fragment compounds translate together after normalization.' It also discloses that 'Yields are not experimentally validated' and that verification of native saved page fit occurs. These are substantive disclosures beyond the annotations, though some phrases (e.g., '0% remains visible') are ambiguous.

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

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

The description is a dense, run-on paragraph with no paragraph breaks or bullet points. It front-loads the main purpose but then continues with a stream of clauses covering cells, ownership, translation, measurement, columns, exclusions, and verification, all in a single block. While every sentence contains information, the lack of structure makes it hard to parse, and it is unnecessarily verbose for what could be organized into clear sections.

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

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

Given the tool's complexity (13 parameters, no output schema, no parameter descriptions in the schema), the description is incomplete. It fails to explain the purpose of expected_source_token, output_dir, or the numeric gap/margin parameters, and it gives no indication of return values or error behavior. The description provides some insight into cells and columns but leaves many essential calling details unresolved, making it insufficient for an agent to correctly invoke the tool without additional knowledge.

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 explains the structure of the 'cells' parameter ('Cells in requested order: {compound_id:3a,fragment_ids:[ID],caption_id:ID|null,yield_percent:82|null}') and mentions 'Columns auto-fit if omitted' for the columns parameter. However, it does not explain document_id, output_dir, expected_source_token, h_gap, v_gap, width, height, margin, pixels, preset, or label_gap. With 13 parameters and only two partially addressed, the description falls far short of covering parameter semantics.

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

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

The description opens with a clear action: 'Create a native scope grid COPY.' It specifies the resource (scope grid) and the operation (create a copy). It also mentions 'Preserves orientation and chemistry' and 'adds caller-supplied compound IDs/yields,' which further clarifies the function. However, it does not explicitly contrast with sibling tools like chemdraw_build_scope_job or chemdraw_plan_scope_job, so some ambiguity remains about when this specific grid-copy tool is preferred.

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

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

The description provides some usage context: it states 'Requires chemistry extra' and lists exclusions ('No reactions/page graphics/nested groups/native symbol graphics'), which imply when not to use it. It also mentions 'Visual review required' as a follow-up expectation. However, it never names alternative tools or gives explicit 'use this instead of X' guidance, leaving routing decisions to the agent.

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

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

Annotations already mark this as read-only, and the description adds meaningful behavioral context: offline execution, optional RDKit usage, explicit normalization behavior, and the absence of salt stripping or tautomer conversion. This goes well beyond the readOnlyHint and gives the agent a precise model of what will and will not happen.

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 compact and front-loaded: purpose first, then outputs, then explicit exclusions and caveats. Every sentence adds useful information without redundancy.

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

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

For a read-only identification tool with no output schema, the description is unusually complete: it defines accepted input forms, lists all return categories, and states important limitations and normalization caveats. An agent has enough information to call it correctly and interpret the result.

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

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

With 0% schema description coverage, the description carries the burden of explaining the value parameter, and it does so by specifying 'explicit SMILES or canonical Standard InChI'. It does not explicitly mention the input_format parameter by name, but the enum and default are in the schema and the description clearly implies format selection.

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

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

The description opens with a specific verb and resource: 'Inspect an explicit SMILES or canonical Standard InChI' and clearly enumerates the outputs. It also distinguishes itself by explicitly saying what it does not do, such as ChemDraw calls, names/CAS resolution, salt stripping, and tautomer conversion, which sets it apart from sibling tools like chemdraw_resolve.

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 communicates when to use this tool: for offline inspection of explicit structure strings with no external ChemDraw call. It also gives clear exclusions ('No ChemDraw call, names/CAS resolution, salt stripping or tautomer conversion'), but it does not name a specific sibling tool to use for those cases.

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 provide readOnlyHint=false and destructiveHint=false, so the tool is expected to be non-destructive. The description adds useful context by stating the original is never opened for editing and that a private working copy is used. However, it does not disclose the working-copy lifecycle, such as whether a handle is returned, whether the copy persists, or whether it must be closed explicitly.

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 short sentences with no wasted words. The core action and supported file formats are front-loaded, and the safety guarantee is placed in the second sentence. Every sentence contributes essential 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 tool with one parameter and no output schema, the description conveys the main purpose and safety boundary. However, it leaves out what happens after the import: what is returned, how to reference the working copy in subsequent calls, and whether there are sequencing constraints with sibling tools like chemdraw_close_working_document. This is a real gap for an agent planning a workflow.

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

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

The schema has a single 'path' parameter with 0% description coverage, so the description must define its meaning. The description does this by clarifying that the path refers to a local CDXML, CDX, MOL, or SDF file. It stops short of specifying path syntax or file-existence requirements, but the core parameter semantics are meaningfully supplied.

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 ('Open'), a precise resource ('private working copy of a local CDXML, CDX, MOL or SDF'), and adds an important distinguishing behavior ('Never opens the original for editing'). This clearly separates it from document-creation, style-import, and editing tools in the sibling list.

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: use this to open a local chemistry file in a safe private working copy. However, it never explicitly says when to use this tool versus alternatives, nor does it rule out cases like importing styles or creating new documents, especially given the large sibling set.

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

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

The description aligns with annotations (readOnlyHint=true, destructiveHint=false) by stating it does not open ChemDraw or modify the source. It adds behavioral details beyond annotations, such as returning validated preset settings, a hash, defaults used, and unapplied properties, and notes that custom fonts are checked on the rendering Mac. This enriches the agent's understanding of side effects and dependencies, though it could have disclosed more about error handling or output format.

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

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

The description is concise, with three sentences that front-load the primary purpose, then add usage guidance and limitations. Every sentence provides value—no filler or redundancy. It is well-structured for quick parsing by 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?

For a simple read-only tool with one parameter and no output schema, the description is fairly complete. It specifies the input type, what it returns (validated settings, hash, defaults, unapplied properties), and how to use the result. It also mentions limitations. Minor gaps include lack of error behavior and exact return structure, but these are not critical for a straightforward operation.

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

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

With a single parameter 'path' and 0% schema description coverage, the description must clarify the parameter's meaning. It implicitly conveys that 'path' points to a local .cds/.cdx/.cdxml file by stating the tool reads such files, which adds some context. However, it does not explicitly describe the parameter, its format, or any constraints (e.g., absolute vs. relative path), leaving room for interpretation. The description partially compensates for the lack of schema coverage but not fully.

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

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

The description clearly states the tool's function: reading a local .cds/.cdx/.cdxml document style without modifying it. It explicitly names the resource type and the non-destructive nature, and the mention of returning preset settings to be passed to draw/polish/grid/apply_style distinguishes it from sibling tools like chemdraw_import_file or chemdraw_create_lab_style.

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

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

The description provides clear usage context by instructing to pass the returned preset object to draw/polish/grid/apply_style, indicating when to use this tool. It also states limitations (only typography and bond settings, not template artwork, page geometry, or colour palette), which guides appropriate usage. However, it does not explicitly name alternatives or state when not to use it, so it falls 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description independently says 'read-only snapshot', so there is no contradiction. It adds useful extra context beyond the annotations by enumerating what is returned and warning that 'Ownership in an annotation recipe is not a native moving attachment guarantee.' This goes beyond the structured metadata without needing to restate safety flags.

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 compact: one core sentence listing the outputs plus one sentence for the ownership caveat. It front-loads the main purpose before the limitation. Some domain jargon like 'measured label boxes' and 'supported native curves' makes it dense, but every sentence contributes distinct 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?

With no output schema, the description acts as the return contract by listing atom/bond IDs, measured label boxes, supported native curves, and source_token. It also covers supported graphics and the ownership limitation. Missing response format details and failure behavior are minor for a simple read-only tool with one required parameter.

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

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

The input schema has no descriptions (0% coverage), and the description never mentions document_id or explains how the parameter selects the snapshot target. Since schema description coverage is low, the description needed to compensate, but it does not. The parameter name is self-explanatory, yet the description adds no semantic value beyond it.

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

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

The opening phrase 'Export a read-only snapshot and list atom/bond IDs, measured label boxes, supported native curves and source_token' clearly states a specific verb, resource, and concrete outputs. It is obviously about annotation inspection rather than generic document inspection, though it does not explicitly differentiate itself from sibling tools such as chemdraw_inspect_document or chemdraw_inspect_symbols.

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 phrase 'for electron-flow annotation' implies when the tool is relevant, and the ownership caveat signals a limitation to keep in mind. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling tools are named. Usage context is implied rather than stated.

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

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

Annotations already declare readOnlyHint and destructiveHint, but the description adds meaningful behavior: 1-based indexing, the need to refresh after edits, the ChemDraw 23 ID caveat, and the explicit statement that atom-level chemistry is not returned. This exceeds the annotation baseline.

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 dense, front-loaded sentences with no filler. Each sentence adds distinct value: the core purpose, a usage caution, and an explicit scope boundary.

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

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

For a read-only inspection tool with a single obvious parameter, the description covers purpose, index semantics, refresh expectations, a known compatibility issue, and what it does not return. Nothing critical is missing.

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

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

Schema description coverage is 0%, so the description carries the burden, but it never explicitly explains the document_id parameter. However, the parameter name is self-explanatory and the tool description makes it clear which document is inspected, so the gap is not severe.

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 ('Inspect') and resource ('1-based molecule indices/bounds and document settings'), clearly distinguishing it from sibling inspect tools like chemdraw_inspect_symbols and chemdraw_inspect_annotations. The explicit exclusion of atom-level chemistry further sharpens its scope.

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 practical usage context: refresh indices after edits, and notes ChemDraw 23 has broken native molecule IDs, implying when to rely on this tool's indices. It does not explicitly name alternative tools or state when not to use it, 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 declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Read and validate' and adds environmental constraints ('No native application or network access') and expected output contents. This goes beyond the structured annotations without contradicting them.

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

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

Two short sentences with no wasted words; the main purpose and key constraints are front-loaded. Every phrase adds information about what the tool does or does not do.

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 one-parameter, read-only inspection tool, the description covers the action, the resource, the returned values, and network/native-access limitations. It does not specify return formatting or error behavior, but the absence of an output schema makes this a minor gap given the tool's simplicity.

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

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

The schema has a single 'path' parameter with zero description coverage, and the description does not explain the expected path format or whether it points to a file or directory. The resource type weakly implies that path locates the package, but the description does not compensate for the missing parameter documentation.

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 action ('Read and validate') and a clear resource ('portable style package'), and it lists the expected outputs (supported settings, version, content hash). This distinguishes it from sibling inspect tools by resource type (lab style vs document/symbols/annotations).

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

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

The description implies the tool is for inspecting a style package, but it does not explicitly say when to prefer it over sibling tools such as chemdraw_list_styles or chemdraw_inspect_document. There are no exclusions or prerequisites stated, leaving usage guidance implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond that by specifying that the tool takes a snapshot (implying non-mutating) and returns a source_token, plus a caveat that a graphical electron dot is not a verified radical state. This adds semantic nuance without contradicting annotations.

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

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

The description is concise (two sentences) and front-loaded with the primary action. It avoids fluff and conveys key points efficiently. It could be slightly more structured (e.g., separating the token explanation), but it is appropriately sized for the tool's simplicity.

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

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

The description covers the core behavior and a relevant caveat, but it does not explain the purpose of the source_token or how it is used downstream. It also does not clarify how this tool differs from other inspection tools (e.g., chemdraw_inspect_document) or mention any prerequisites. Given the single parameter and read-only annotations, it is adequate but not complete.

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

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

With schema_description_coverage at 0% and only one parameter (document_id), the description does not explain the parameter's format, purpose, or constraints. The name is self-explanatory, but the description provides no additional semantics, failing to compensate for the lack of schema descriptions.

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

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

The description clearly states a specific action ('Snapshot native atom/bond/symbol IDs and measured label bounds') and a distinct output ('returning a source_token'). It identifies the resource (symbols in a document) and is not a tautology. However, it does not explicitly differentiate from sibling tools like chemdraw_inspect_document or chemdraw_inspect_annotations, so it loses one point.

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 no explicit guidance on when to use this tool versus alternatives. It mentions supported symbol types (circled charges, electron/lone-pair symbols) but does not state conditions or exclusions. There is no mention of when to prefer this over other inspect tools, leaving the agent to infer usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered and the description does not need to repeat it. The description adds the 'running' scope and the returned fields, which is useful context beyond the annotations, but it does not mention edge behavior such as empty result sets or exact return formatting. This is adequate given the annotations, but not rich.

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

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

A single sentence with the verb and resource front-loaded, followed by a tight list of returned fields. Every word earns its place, and there is no repetition of structured data or 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?

For a zero-parameter, read-only list tool with no output schema, the description states both the scope ('running' documents) and the return content (IDs, names, paths, modified flags). Combined with the readOnly and destructive annotations, an agent has enough information to invoke the tool and interpret its result 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?

The tool has zero parameters and an empty schema, so there is no parameter burden for the description to carry. Per the rubric, a zero-parameter tool earns a baseline of 4; no additional parameter explanation is needed.

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 the specific verb 'List' with the resource 'running ChemDraw documents' and enumerates exactly what is returned: unique IDs, names, paths and modified flags. This clearly distinguishes it from sibling tools such as chemdraw_list_styles and chemdraw_inspect_document, so an agent can identify its purpose without inspecting schemas.

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

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

The description implies usage: call this when you need to enumerate currently running ChemDraw documents and their IDs. However, it provides no explicit when/when-not guidance and names no alternatives, even though siblings like chemdraw_inspect_document, chemdraw_close_working_document, and chemdraw_create_document offer related document operations. The usage context is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns numeric style presets and clarifies that it doesn't cover chemistry or layout engines, which is extra context beyond the annotations. It doesn't describe return format, but for a list tool with no output schema, that's a minor gap.

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

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

The description is extremely concise—one sentence with no fluff. It front-loads the core purpose ('List numeric style presets') and adds qualifying context in the second clause. Every word earns its place, and it's perfectly sized for a simple list 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?

For a zero-parameter, read-only list tool, the description covers the essentials: what it lists, the scope (defaults and overrides), and what it excludes. Given the annotations cover safety and the schema is empty, it's complete enough for an agent to know when to call it and what to expect. Missing explicit output format is a minor gap.

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

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

The tool has zero parameters, so the input schema is trivially complete. The description doesn't need to add parameter meaning, and it provides sufficient context about what the list contains. Baseline 4 is appropriate for a no-parameter 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?

The description clearly states it lists numeric style presets, distinguishing itself from related style operations like create_lab_style or apply_style. It specifies the scope (defaults plus explicit text/bond overrides) and clarifies what it is not (chemistry or layout engines), which differentiates it from sibling tools.

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

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

The description implies when to use this tool: when you need to list available numeric style presets. It doesn't explicitly state when not to use it or name alternatives, but the distinction from chemistry/automatic layout engines suggests what this tool is not for. With 36 siblings, more explicit exclusions would help, but the context is reasonably clear.

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 provide readOnlyHint=false and destructiveHint=false, indicating a mutating operation that is not destructive. The description aligns by stating it creates a 'new native copy' (non-destructive) and adds key behavioral context: it carries owned captions/symbols, requires equal translation for cross-owner curves, and explicitly disclaims automatic manual-drag attachment or collision-free layout. This goes beyond annotations to set expectations about side effects and limitations.

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

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

The description is two sentences: the first packs the action, scope, and key nuance (cross-owner curves) efficiently; the second adds return value and explicit non-claims. Every clause adds value, front-loads the core behavior, and avoids fluff.

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

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

The description covers the tool's purpose, key behaviors, and limitations, which is strong for a tool with no output schema and nested objects. However, with 5 required parameters and no schema descriptions, an agent might still have questions about expected_source_token and output_dir semantics, and the 'ownership' object structure isn't elaborated. Still, the description is quite complete for the core operation, so a 4 is justified.

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 explains the core 'moves' parameter (owner_key, delta), mentions the ownership sidecar, and refers to 'ownership' implicitly. However, it does not describe each parameter in detail (e.g., output_dir, expected_source_token), leaving some gaps. The description adds significant meaning for the main complex parameters, so a 4 is appropriate given the 0% coverage.

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 what the tool does: it moves explicit owners by specifiable deltas in a new native copy, and it enumerates what is carried along (captions, symbols, internal curves). It distinguishes itself from other moving/editing tools by specifying the 'explicit owner' mechanism and the 'new native copy' behavior.

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

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

The description implies when to use this tool (when moving owned elements with explicit owner definitions) and gives a specific constraint for cross-owner curves. It doesn't explicitly name alternative tools, but the sibling context includes tools like chemdraw_edit_document and chemdraw_clean, which likely handle broader edits. The lack of explicit 'use X instead' is a minor gap, but the conditional guidance for cross-owner curves is concrete.

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

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

Annotations already mark the tool read-only and non-destructive, and the description adds useful behavioral detail: it runs offline, yields null, and never implicitly accepts candidates. This goes beyond the schema and annotations and clarifies the planning contract clearly.

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 with no redundancy and front-loads the main purpose. The wording is slightly telegraphic and the phrase 'All yields null' is awkward, but every sentence contributes substantive 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?

It provides the essential inputs and a clear behavioral contract despite the bare nested job schema and missing output schema. However, the exact shape of handle_atom_map and the categories structure is not fully specified, so an agent may need to infer details about the nested argument.

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

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

The schema provides only an opaque job object with 0% description coverage, but the description names required internal fields: mapped parent_smiles, handle_atom_map, and ordered groups {label,categories}. It also distinguishes build-time selected_candidate_ids/accept_all from planning semantics, which meaningfully compensates for the empty schema even though exact types and nested structures remain underspecified.

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 clear function: offline planning of a standard aromatic scope with explicit candidate selection and category grouping. It is distinguishable from build_scope_job and propose_scope by emphasizing planning and offline mode, though it is phrased as a noun phrase rather than an active verb.

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 context that this is the offline planning stage, expects mapped parent_smiles, handle_atom_map, and ordered groups, and contrasts planning with building by noting that building requires selected_candidate_ids or accept_all=true while planning never implicitly accepts. It does not explicitly name alternative sibling tools or give when-not-to-use conditions.

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 only bare annotation hints (readOnlyHint=false, destructiveHint=false), the description richly discloses behavior: it never edits the source, requires an extra feature, fails closed on unsupported content, preserves specific chemical attributes, does not auto-clean, and explicitly warns that checks establish preservation not correctness. This far exceeds the annotation baseline and gives agents essential safety expectations.

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

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

The description is dense but every sentence carries critical operational information; the main purpose is front-loaded in the first sentence. It is somewhat long and could be structured into bullet points for scannability, but it avoids filler and earns its length.

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

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

For a tool with 10 parameters, no output schema, and minimal annotations, the description covers behavior, limitations, prerequisites, and preservation scope well. It omits explanation for several styling/output parameters (gap, label_gap, pixels) and does not describe return values, but the core calling context is sufficiently complete for an agent to use it safely.

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 gives meaning to 'layout' and the maps ('Row layout requires explicit fragment-to-caption and arrow-to-condition ID maps from analyze; unassigned text is rejected'), but it does not explain 'gap', 'label_gap', 'width', 'pixels', or 'preset' beyond their schema titles. Partial compensation only.

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

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

The description opens with a specific verb and concrete deliverables ('Create a new normalized native drawing plus editable CDXML, SVG, PNG, before/after HTML, recipe and audit') and immediately disambiguates from siblings by stating 'Never edits the source' and 'Does not run native cleanup automatically.' This distinguishes it clearly from chemdraw_edit_document, chemdraw_clean, and chemdraw_export.

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 provides explicit prerequisites ('Requires chemistry extra', 'Flat one-page drawings only') and failure conditions ('queries/groups/abbreviations fail closed', 'unassigned text is rejected'), plus a dependency on 'analyze' for row-layout maps. It doesn't explicitly name alternative tools, but the conditions effectively tell an agent when this tool is appropriate and when to avoid 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?

The description adds substantial behavioral context beyond the readOnly/destructive annotations: it enumerates the exact generated variant classes, the stable graph IDs/SMILES/labels/rationale/yields output, preservation of parent graph/stereo, and the absence of drawing or reaction-prediction behavior. This goes well beyond the annotation hints and sets accurate expectations.

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 front-loads the core purpose, then moves through input constraint, output contents, limitations, and the next action. Each sentence adds a distinct piece of information with no fluff or repetition; the length is justified by 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?

For a tool with no output schema and only three parameters, the description covers the required input shape, what outputs to expect, what is preserved, what is not performed, and what to do next. An agent has enough information to decide to call it and to interpret its result.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it does for the two required parameters: parent must be an isolated monosubstituted ring with an atom-mapped carbon attached to the handle. It does not explicitly call out the optional 'profile' parameter, but that parameter is constrained to a default constant, so the omission is minor.

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 action and object: 'Propose a standard aromatic substrate scope offline, not experimental results.' It states exactly what the tool produces (deduplicated parent, electronic, halogen, Me, steric variants) and what it does not do (native drawing or reaction prediction), so an agent can distinguish it from related scope/drawing 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 gives clear input prerequisites ('Parent requires a uniquely atom-mapped benzene carbon attached to the existing reaction handle on an isolated monosubstituted ring') and a downstream instruction ('Review/select candidates, then call draw_structures'). It does not, however, explicitly contrast this tool with sibling propose/decorate/scan scope tools or state when not to use them.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint false, and the description adds substantial behavior beyond them: returns up to 20 candidates, provenance, ambiguity/truncation and graph-validation results; network is denied by default and requires allow_network=True; no retries or provider fallback. No contradiction with annotations 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?

Four dense sentences with no filler. The first sentence front-loads the action and key constraint, and every subsequent sentence adds behavioral or workflow detail that is not present in the schema or annotations.

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 3-parameter tool with no output schema, the description is complete: it states what the tool returns, the network precondition, the required follow-up action, and the explicit limitations. An agent has enough information to invoke it correctly and interpret the result.

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

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

Schema description coverage is 0%, so the description carries full parameter-semantics burden. It explains query as an explicit name or CAS, implies input_kind enum values (name/cas), and clarifies allow_network behavior ('allow_network=True', 'Network denied by default'). All three parameters gain meaning beyond the raw schema.

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

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

States a specific verb 'Resolve' with a clear resource: an explicit name or CAS query via PubChem. It also differentiates itself from siblings by listing non-goals ('No silent candidate selection, native drawing, retries, provider fallback or CAS Registry certification'), so an agent can tell what this tool is and is not for.

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 when-to-use context: resolve explicit name or CAS queries through PubChem. It also provides when-not-to-use guidance: no silent candidate selection, no drawing, no retries, no provider fallback, and instructs the agent to review and select a valid candidate before drawing. It does not name a specific sibling alternative, but the exclusions are sufficient for 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?

The description adds meaningful behavior beyond the annotations: conflicting recipe settings are rejected, the actual package/hash is retained beside the output, native exports use ChemDraw, and numerical conventions do not substitute for chemical review. It does not disclose what gets created or overwritten or how errors are surfaced, but it reveals several important operational traits.

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

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

The description is appropriately short and front-loaded with the core purpose. Every sentence adds information, though several phrases are compressed to the point of ambiguity (e.g., 'locked portable lab style', 'numerical conventions'), which slightly reduces clarity.

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?

This is a complex tool with four required parameters, an open recipe object, an enum workflow, and no output schema. The description provides only fragments: a CDXML requirement, a conflict-rejection rule, and a caveat about ChemDraw exports. It does not define the workflow values, recipe shape, style/packaging mechanics, or expected outputs, so an agent would need external knowledge to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints at recipe settings, a CDXML path, and output/package/hash behavior. It does not clarify the meaning of package_path, output_dir, the workflow enum values, or the structure of the recipe object, leaving four required parameters largely unexplained.

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, 'Run a native workflow', plus a key distinguishing constraint: the workflow uses a 'locked portable lab style'. It also names the grid/symbols workflow requirement, but 'native workflow' and 'locked portable lab style' remain somewhat jargon-heavy and the description does not explicitly differentiate from sibling build/apply/export tools.

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

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

The description gives useful context: this tool runs workflows with a fixed lab style, rejects conflicting recipe settings, and requires an input CDXML path for grid/symbols recipes. However, it does not explicitly state when to prefer this over sibling tools like chemdraw_build_scope_job or chemdraw_apply_route, nor what conditions would make it inappropriate.

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 goes further by stating that it preserves the parent graph/stereo, retains alternative provenance for duplicates, and does not invent yields or reaction predictions. This adds valuable context about the tool's behavior beyond the annotation flags.

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

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

The description is concise, with every sentence providing useful information. It front-loades the core function and then adds constraints and guidance. No fluff or redundant wording.

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 (4 params, 0% schema coverage, no output schema), the description covers everything an agent needs to call it correctly: what inputs are expected, how to select them, limitations, and what happens to the results. It even points to the next tool for output.

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

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

The description explains what the parameters represent (explicit mapped H-bearing aromatic carbon sites, curated substituents, one site at a time) even though the schema provides no descriptions. It clarifies the meaning of 'site_atom_maps' as explicit mapping and 'substituents' as the curated list, which is essential given 0% schema coverage.

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

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

The description clearly states the tool proposes substitutions at specific aromatic carbon sites, specifying the types of rings and substituents. It distinguishes itself from sibling tools like 'decorate_scope' and 'propose_scope' by emphasizing the offline, curated nature and the requirement for explicit mapped sites.

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

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

The description explicitly says to select explicit candidates and use draw_structures for native output, directing the agent to the appropriate next step. It also clarifies limitations (one site at a time, cap at 100 requests) which helps the agent decide when to use this tool versus others.

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, so no contradiction. The description adds meaningful behavioral constraints: it rejects atom-label sources, requires an explicit symbol, returns snapshot-bound candidate recipes and a clearance audit, and explicitly says native arrowhead ink still needs visual review. It does not fully describe failure modes or the exact shape of the candidate recipes, but with readOnlyHint covering safety, this is strong.

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 compact and information-dense. Every sentence contributes: the first sentence defines the tool's exact function, the second and third define input constraints, the third defines non-behaviors, and the last describes the return type. It is well-structured and front-loaded with the core behavior.

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

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

Given the tool's moderate complexity (8 params, nested objects, no output schema) and readOnlyHint annotations, the description covers what the tool does, what inputs are valid, what it does not do, and what it returns. The main omission is parameter semantics for the remaining options, but the defaults and names make them inferable. This is complete enough for an agent 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 description coverage is 0% and there are 8 parameters including nested objects. The description explains the meaning of source and target in detail (source types accepted/rejected, target as explicit atom/bond ID), which compensates for the schema's lack of descriptions. However, it does not explain clearance, electrons, line_width, fishhook_side, or max_candidates, leaving those to be inferred from defaults and names.

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 (suggest) and resource (bounded cubic electron-flow paths) and clearly distinguishes it from siblings by specifying it uses measured obstacles and returns candidate recipes plus clearance audit, not actual route application. It differentiates from chemdraw_apply_route, which likely executes routes, and from chemdraw_plan_scope_job.

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 explicit eligibility criteria: source must be an explicit displayed CircleMinus/LonePair for two electrons, Electron dot for one electron, or donating bond; atom-label sources are rejected; target must be an explicit atom or bond ID. It also states no chemistry inference or automatic route selection, ruling out use cases where the user expects the tool to interpret chemistry.

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