draw_line

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

With no annotations, the description carries the disclosure burden. It does add real domain behavior: coordinates are in mm, sketch_index 0 means the latest sketch, and a construction line becomes a revolve axis and is excluded from the profile. It omits whether the call mutates the open document, requires a transaction, or what happens when no sketch 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?

Front-loaded one-sentence purpose followed by a compact per-argument list; every line carries information (units, endpoints, index convention, construction semantics) with no filler.

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

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

An output schema exists so return values need not be described, and parameters are mostly covered. However, a mutation tool with zero annotations and 7 parameters should state prerequisites (an active document/part and which sketch is being edited) and whether the geometry is committed immediately, which it does not.

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 only 14% (just the instance param), so the description must compensate and largely does: x1/y1/x2/y2 are labeled start/end in mm, sketch_index is explained as '0 = latest sketch', and construction is explained semantically, not just as a boolean. The instance parameter is left entirely to the schema.

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

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

States a specific verb and resource ('Draw a line in a sketch') plus the unit convention (mm), which makes it clearly distinct from draw_rectangle, draw_circle, draw_arc and draw_polygon. It stops short of explicitly disambiguating against the other sketch-drawing siblings or telling the agent which geometry primitive fits which situation.

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 guidance on when to use this versus draw_closed_profile or the other drawing primitives, and no stated precondition such as an active document or an existing sketch. The only contextual hint is the inline note that sketch_index 0 targets the latest sketch, which is parameter trivia rather than usage guidance.

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