feature_revolve

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

With zero annotation coverage the description carries the full burden, and it does: it discloses rollback/atomicity ("INVALID_PARAMS (nothing changed)", "FUSION_API_ERROR and the timeline is rolled back"), the geometric precondition that the profile must lie on one side of the axis, and the constraint that surface bodies require new_body/new_component. These are exactly the non-obvious behaviors an agent needs before committing a 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-loads the one-line purpose, then organizes detail under clear inline labels (Units:, Refs:, Extents:, Errors:, Returns:, Examples:), and the examples are compact and functional. It is on the long side and the Extents paragraph partly restates the schema's extent description, but nearly 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 7-parameter mutation tool with a discriminated-union `extent`, no annotations and no output schema, the description supplies everything missing: an inline Returns shape (feature ref, health state, created/modified/removed bodies, component), error/rollback semantics, and worked invocation examples. Nothing an agent needs to call it correctly is absent.

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 100%, so the baseline is 3, but the description adds genuinely non-obvious semantics: `units` applies only to {"sketch", "point"} specs (a caveat absent from the schema), symmetric splits the angle about the sketch plane, and to_entity starts toward or away from the sketch normal. Extent field mapping is largely repeated from the schema, keeping it from a 5.

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 ("Revolve sketch profiles or planar faces around an axis") and grounds it with concrete outcomes (shafts, pulleys, bottles) plus an operation variant ("grooves (operation=\"cut\")"). This is clearly distinguishable from feature_extrude, feature_sweep and feature_loft, and no sibling would be selected in its place.

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 explicit prerequisites and routing: profiles come from sketch_draw / sketch_profiles, the axis from sketch_draw refs, construction_axis, origin:X|Y|Z or an inspect_query edge, and it says to describe created bodies with inspect_* since geometry is not returned. It also constrains is_solid=false to new_body/new_component. It stops short of naming when to prefer feature_extrude or feature_sweep instead, so no explicit exclusion against siblings.

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