form_convert_to_brep

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

With no annotations, the description carries the full burden and does well: it discloses that the copy is independent of later form edits, that the form remains in the timeline hidden by default, and the specific failure mode (T-spline body with no B-Rep such as an open/broken mesh yields FUSION_API_ERROR with nothing created). It doesn't discuss component placement of the new body or undo/rollback behavior, but the key side effects are covered.

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 the core action, then independence semantics, then errors, then the return shape — a sensible priority order with no filler. The line-broken formatting and the brief API aside are slightly verbose but each clause carries information an agent needs.

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?

No output schema exists, and the description compensates by enumerating the returned keys (body, name, source, base_feature, is_solid) including the nullable base_feature case. Combined with the error path and side-effect disclosure, an agent has everything needed to call this correctly and interpret the result.

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 already 100%, so the baseline is 3; the description adds value by explaining that name applies to the new body and that hiding the form (and its B-Rep) is the default outcome, giving the hide_form flag operational meaning. The body parameter's accepted ref types are documented in the schema itself rather than the 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 and resource: make an independent B-Rep copy of a T-spline body's B-Rep, created in a base feature of a parametric design. It immediately distinguishes itself from siblings like form_get_tsm (read the T-spline) and form_create_from_tsm (the reverse direction) by naming the concrete output artifact.

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?

Explicitly frames the output as the solid to feed downstream features (shell, fillet, join), which tells an agent why and when to reach for it. It also pre-empts a plausible wrong turn by noting the Fusion API has no 'Convert' command. It stops short of naming a specific sibling alternative to use instead, so it isn't a full 5.

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