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

With no annotations, the description carries the full burden and does add real behavioral context: it operates on the ACTIVE drawing, it does NOT save, dimensions are self-checked, and the agent should inspect result.check and the PNG. It stops short of stating permissions, side effects on existing drawing content, or whether the non-save result is discardable.

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?

Dense and front-loaded: purpose first, then the capability list, then the key constraints (does not save, absolute path, steps subset) and the verification hint. No wasted sentences, though the long comma-run capability list is packed tightly.

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?

A mutation tool with no annotations and an output schema. The description supplies the crucial non-obvious details (active-document scope, no save, absolute spec_path, post-run check) that the structured fields lack. Only the undocumented `strict`/`title_block` parameters and permission requirements are unaddressed.

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%, so the description must compensate. It meaningfully documents `spec_path` (must be absolute) and `steps` (subset selection with an example), but leaves `strict` and `title_block` entirely unexplained in both schema and prose.

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

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

States a specific verb (Build) and resource (the ACTIVE SolidWorks drawing from a spec), and enumerates the operations performed (scale, layout, dimensions, GD&T, export). It distinguishes itself by scoping to the active drawing and being spec-driven, though it never names a sibling like swdraw_revise or swdraw_validate_spec to sharpen the boundary.

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

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

The example for `steps` (["clear", "dimensions", "gdt", "export"]) implies partial-run usage and the closing note implies a verification workflow, so usage is inferable. It never states when to prefer this over siblings such as swdraw_revise or swdraw_validate_spec, nor any prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the key safety trait ('read-only'). However, it says nothing about permissions, side effects, or behavior of the probes, so the coverage remains partial.

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, front-loaded sentence with no filler, leading with the safety trait before the value list. Its terseness borders on under-specification, but structurally it is efficient.

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

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

An output schema exists, so return values needn't be explained, and the read-only nature is stated. Still, with 0% schema coverage and no annotations, an agent gets no guidance on when to choose this over validation siblings or what the discriminator strings fully imply.

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%, so the description must compensate. It usefully enumerates the valid 'what' values ('views', 'selection', 'annotations', 'refs') and hints that 'refs' pairs with args.paths, but it doesn't define the expected format of 'what' or clarify args for the other values.

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 ('probes') and resource ('the active drawing') and enumerates the probe targets ('views', 'selection', 'annotations', 'refs'). The 'read-only' framing also separates it from mutating siblings like build_drawing or revise, though no sibling is named 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named (e.g., vs swdraw_validate_spec). The agent can infer read-only inspection is intended, but selection conditions are left entirely 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?

No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses that it acts on the active drawing by default with a fallback to args.drawing, and that a PNG preview is emitted for visual checking, but says nothing about where files are written, whether existing files are overwritten, or what preconditions (e.g. an open drawing) are required.

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 front-loaded sentence with no filler; the primary action and its outputs come first, with parameters relegated to parentheses.

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

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

An output schema exists, so return values need not be described, and the description covers the core action and both artifacts. However, with no annotations and an opaque args object, more detail on required keys, file output location, and preconditions would be needed for an agent to invoke this reliably.

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

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

Schema coverage is 0% and the single 'args' parameter is an opaque anyOf object, so the description is the only source of parameter meaning. It names three keys (drawing, path, png), which is genuinely valuable, but the syntax and structure of args remain unclear and the naming is ambiguous.

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 (Export) and resource (active drawing) plus the concrete outputs (PDF, PNG preview). This clearly differentiates it from siblings like swdraw_build_drawing and swdraw_revise, which produce or modify drawings rather than exporting artifacts.

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 parenthetical '(or args.drawing)' implicitly defines the default-vs-override behavior, so usage can be inferred, but there is no explicit when-to-use/when-not guidance or reference to alternative tools. Adequate but leaves the agent to infer the workflow context.

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

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

With no annotations, the description carries the full burden, and it does disclose the key trait: both actions delete content ('delete and re-insert', 'delete copies'), which signals a destructive mutation. It does not state reversibility, permission needs, or what the 'save' flag actually controls, so the disclosure is partial.

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 tight sentences, each front-loaded with the action keyword and its effect, with no filler. Slightly dense parenthetical arg lists but still economical.

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

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

An output schema exists, so return values need no explanation, and the description usefully supplies the valid action names that the schema omits (no enum on 'action'). However, for a nested arbitrary-args tool the argument semantics remain thin, leaving the agent to guess at 'lines', 'values', and 'save'.

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 'args' is an untyped nested object, so the schema explains nothing. The description partially compensates by listing the expected arg names per action (lines, pos, values, drawing, save) and clarifying pos is in mm, but it gives no meaning for lines, values, or save.

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 two concrete actions on a specific resource: 'replace' deletes and re-inserts the numbered NOTES: block, and 'dedupe' deletes unnumbered copies of that block. This is a clear verb+resource statement. It does not, however, distinguish the tool from siblings like swdraw_number, swdraw_renumber, or swdraw_revise, which likely also touch numbering.

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

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

Usage is only implied by the effect of each action: you would pick 'replace' to rebuild the block and 'dedupe' to strip copies that lost numbering. There is no explicit when-to-use statement, no prerequisites, and no guidance on choosing between this and the numbering siblings.

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

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

With no annotations, the description carries the full behavioral burden and fails it. It does not say whether 'check' is read-only while 'next-part'/'next-assembly' mutate the assembly by reserving numbers, nor does it disclose permissions, idempotency, or side effects — the read/write distinction can only be guessed from action names.

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?

There is zero padding and the action list is front-loaded, but the telegraphic, verbless style ('Part numbers.') costs parseability for a multi-mode tool. It is short without being efficient — key semantics were cut, not compressed.

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

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

An output schema exists so return values need not be described, but for a tool with three distinct modes, a nested free-form args object at 0% schema coverage, and no annotations, the description omits argument meaning, side effects, and error behavior. It is not complete enough to call the tool confidently.

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 'args' is an opaque object with additionalProperties=true, so the description's mapping of args.numbers, args.assembly, args.used and args.discipline to specific actions is real added value. It still never explains what these values mean (e.g. is 'used' a list of already-consumed numbers?), their types, or formats.

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

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

The fragment 'Part numbers.' names the resource but supplies no verb, and the tool's actual function (checking and generating part numbers) must be inferred from the action list. The three action tokens do differentiate it from siblings like swdraw_renumber, but only implicitly.

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 action-to-args mapping ('check' (args.numbers), 'next-part' (args.assembly, args.used), etc.) implies which mode to pick, which is genuine routing guidance. However, there is no statement of when to use swdraw_number versus swdraw_renumber or swdraw_register, and no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at file generation ("workbook", "out" key) but never states what file is written, where, whether existing files are overwritten, or how the drawings/revisions/data inputs interact. For a mutation-style export tool with zero annotation coverage, this is a notable 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?

Front-loads the purpose, then lists keys compactly. The nested-bracket notation is dense but information-bearing; there is little filler. Only the trailing "numbering_profile" is easy to miss.

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

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

An output schema exists, so return values need not be explained, and the keys are documented. However, for a tool with nested objects and no annotations, the description omits where output is written, overwrite semantics, and how the alternate 'data' path relates to the inline keys, leaving meaningful gaps for correct invocation.

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

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

Schema coverage is 0% and the schema is an opaque passthrough object (additionalProperties: true), so the description does real work by enumerating keys: out, title, drawings, revisions, data, numbering_profile, plus nested field shapes for drawings and revisions. It adds genuine meaning the schema cannot convey, though it leaves relationships (e.g., drawings vs data precedence) unstated.

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

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

States a specific verb+resource ("Generate the drawing register workbook") and enumerates the three component sheets (Register / Revision History / Numbering), so the output is concrete. It does not distinguish itself from siblings like swdraw_number, swdraw_renumber, or swdraw_export_pdf, which leaves some ambiguity about which tool produces the register.

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

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

No when-to-use vs alternatives, no prerequisites, and no exclusions. The description names its keys but never explains when an agent should reach for swdraw_register versus swdraw_number or swdraw_renumber, all of which operate on overlapping drawing-numbering concepts.

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

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

With no annotations, the description carries the full burden, and it does disclose the mutating pipeline (Save As, notes swap, supersede/folder rename) which reveals real side effects. However, it omits permission requirements, failure behavior, and whether originals are preserved or overwritten, leaving significant behavioral gaps for an unannotated mutation tool.

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

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

Front-loads the purpose, then packs the workflow and key list into one dense sentence with no filler. The trailing key dump is hard to scan but every token carries information.

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

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

An output schema exists so return values need not be described, and the multi-step workflow is conveyed. But for a complex, unannotated mutation tool, the absence of usage guidance, per-key semantics, and failure/permission behavior leaves it only minimally complete.

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

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

Schema coverage is 0% and the schema is an opaque 'args' object with additionalProperties, so the description is the only source of parameter info. It lists twelve keys (drawing, old, new, old_parent, notes_lines, save, supersede, etc.), which is meaningfully more than the schema, but gives no type, format, or semantics for any of them.

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

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

The opening states a specific verb+resource: 'Reference-safe renumber of a part and its drawing,' and the parenthetical enumerates the sub-steps (part Save As, notes swap, drawing Save As, dependency check). This is clearly distinguishable from most siblings, though it does not explicitly contrast with swdraw_number or swdraw_revise, which could be confused with renumbering.

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

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

The description explains what the tool does internally but never states when to reach for it versus alternatives like swdraw_number, swdraw_revise, or swdraw_build_drawing. No prerequisites, triggers, or exclusions are given.

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

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

No annotations exist, so the description carries the full burden. It does disclose real side effects beyond a bare 'update'—moving dimensions/GTols to model points, shifting views, and an optional 'save' key—which tells the agent the drawing geometry/annotations get mutated. However it omits prerequisites, reversibility/undo behavior, and permission or failure semantics.

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 compact pass that front-loads the purpose and then the affected artifacts and keys. Presence of a colon-delimited key dump is dense but information-bearing; little filler. Could be split for readability but no wasted sentences.

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

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

An output schema exists, so return values needn't be described, and the key list covers the input surface. But for a multi-effect mutation tool with no annotations the description lacks prerequisites, ordering constraints between the listed actions, and error behavior, leaving the agent guessing how to drive 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 coverage is 0% and the schema is an opaque free-form 'args' object, so the description is the only documentation. It lists 13 keys (rev, row, desc, date, drawn, approved, approver_name, approved_date, finish_note, shift_views, notes_pos, move_dims, move_gtols, save), which meaningfully compensates, but gives no format or meaning for any key (e.g. expected date format, what 'SEE NOTE n' expects).

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

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

The description gives a clear verb+resource ('Apply a revision to a drawing') and enumerates the concrete sub-actions a revision performs (rev row, REV box, approval, SEE NOTE n, view shifts, moving dims/GTols). It is distinctly a revision operation, separable from siblings like swdraw_renumber or swdraw_notes, though the dense jargon blurs the boundary slightly.

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 notes the target may be the active drawing or args.drawing, which is minor context, but gives no explicit when-to-use/when-not guidance and never names an alternative sibling (e.g. swdraw_renumber for renumbering vs. revise for revisions). The agent must infer routing from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose two genuinely useful facts beyond the schema: scripts must live in SWDRAW_SCRIPTS_DIR and the in-script contract is `import swdraw as sw; sw.args(); sw.result({...})`. However, it omits that this executes arbitrary code, what happens on script error/timeout, and whether the script can mutate drawing state — material for an execution 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?

A single sentence with the operative constraint (SWDRAW_SCRIPTS_DIR) up front and an inline code example that conveys the API contract in fewer tokens than prose would. Nothing is redundant.

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

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

An output schema exists, so return-value explanation is unnecessary, and the core invocation contract is covered. For an arbitrary-code-execution tool with zero annotations, though, the definition leaves out failure behavior and side-effect scope, which an agent needs before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that `script` names a file under SWDRAW_SCRIPTS_DIR and the `sw.args()` snippet implies that the `args` object is what the script reads, but it never states the format, defaults, or how args maps onto the script's inputs.

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 (Run) and a clearly bounded resource (your own Python scripts located in SWDRAW_SCRIPTS_DIR), which an agent can immediately distinguish from siblings like swdraw_build_drawing or swdraw_validate_spec that operate on specs rather than user code. It stops short of explicitly naming an alternative or exclusion, so it is clear but not fully differentiated.

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 says what can be run but never says when to reach for this tool instead of the ten purpose-built siblings. There is no guidance on prerequisites, when scripting is preferable to a declarative tool, or when it should be avoided — the agent must infer the escape-hatch role entirely.

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

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

With no annotations, the description carries the full burden, and it does disclose the critical trait that the operation is a DRY RUN unless dry_run is false. It does not disclose where files are moved to, whether the move is reversible, what 'live' means, or any permission requirements for what is effectively a destructive filesystem mutation.

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

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

Front-loaded with purpose, immediately followed by the safety-critical dry-run default, then a compact key list. Three short sentences with essentially no waste, though the key list is terse to the point of under-explaining.

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

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

An output schema exists, so return values need not be described. For a mutation tool with no annotations and an opaque nested args object, the description covers the dry-run default and key names but omits the destination of moved files, the definition of 'live', and failure/error behavior.

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

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

Schema coverage is 0% and the schema is an opaque free-form 'args' object, so the description's key list (working, keep, superseded, move_folders, dry_run) is the only parameter documentation available. It glosses only 'keep (glob list)' and leaves the meaning and types of superseded, move_folders, and working unexplained, so it partially compensates but falls short of the 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 concrete verb (move) and resource (files that aren't live) scoped to a working folder, which is specific enough to distinguish it from siblings like swdraw_build_drawing or swdraw_validate_spec. It stops short of explicitly contrasting itself with any named 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 condition for use is implied by 'files that aren't live out of a working folder', and the dry-run default gives a safe entry point. However, there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives among the sibling tools.

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

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

No annotations, so the description carries the full burden. 'Check' and 'No SolidWorks needed' convey that this is a non-mutating, dependency-free operation, which is useful, but it says nothing about failure modes (e.g., malformed YAML, nonexistent path) or which SolidWorks features the checks depend on.

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 front-loaded sentence with zero filler; the file-format and path constraints are packed in without padding.

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

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

An output schema exists, so return values need not be explained, and the description covers what is validated, the input format, and the absence of a SolidWorks dependency. Adequate for a one-parameter validator, with only edge-case behavior left implicit.

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

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

Only one parameter with 0% schema description coverage, so the description must compensate and largely does: it specifies the accepted formats (YAML/JSON) and that an absolute path is required. It could still note whether the file must exist, but the key semantics are covered.

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

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

States a specific verb (Check) plus the resource (drawing spec) and enumerates exactly what it looks for: missing keys, bad points, dimensions without `expect`. That precision clearly separates it from build/revise/export siblings without needing to name 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?

'No SolidWorks needed' implies an offline, pre-flight use case and is a genuine usage signal, but the description never states when to choose this over swdraw_build_drawing or other siblings, nor any exclusions. Usage 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.