swdraw_build_drawing

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.