revolve_sketch

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

Annotations already declare this as a non-read-only, non-destructive, non-open-world mutation, so the safety profile is covered. The description adds genuine geometric validation rules (axis must lie in the sketch plane, must not cross the profile) that are not in annotations or schema. It stops short of describing what happens on constraint violation or how new/add/cut differ behaviorally, keeping this at a moderate score.

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, zero waste, and front-loaded with the core action before the constraint. The constraint sentence earns its place by preventing a common geometric error.

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 eight-parameter tool with seven profile variants and an output schema, the description covers only the action and one geometric constraint. Operation modes, angle limits, and plane selection are handled by the schema, so nothing critical is missing, but the description could add more domain guidance (e.g., that operation=new creates a separate body) to be 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 moderate (63%) and the schema itself richly documents operation semantics, plane behavior, and shape variants. The description does not explain the axis, angle, or plane parameters beyond the plane-membership constraint already implied. With the schema doing most of the parameter documentation, baseline 3 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 and resource: "Revolve sketch profiles about an axis," and adds concrete example artifacts (shafts, pulleys, turned parts) that make the purpose tangible. It does not name the sibling sketch_extrude to differentiate when to revolve versus extrude, but the verb itself is distinct enough for an agent to select it over the extrusion tool.

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 examples (shafts, pulleys, turned parts) imply typical use cases, and the axis constraints imply preconditions. However, there is no explicit "use this instead of sketch_extrude when..." routing, and no named alternatives or exclusions, leaving the agent to infer selection from the examples alone.

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