round

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 units (mm/degrees), the failure/rollback model ("each feature call either ends with an active feature or is rolled back"), persistence ("nothing is saved unless model_save is called"), and the verification path (model_info volume/bound_box, preview_image). It does not state permission/auth needs or what happens if the radius exceeds local geometry, which keeps it short of a 5.

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?

The tool-specific content is two sentences at the end; everything before it is shared family boilerplate about axes, units, saving, and mirroring. It is not wasteful per se, but the structure is badly front-loaded — the actual operation should lead, with the global preamble trailing or omitted.

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 5-parameter geometry mutation with no output schema, the definition covers the essentials an agent needs: how to source edge ids, how tangent selection works, unit conventions, rollback on failure, that saving is a separate step, and how to verify the result. Only error specifics (e.g., radius too large for the adjacent faces) are left implicit.

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 60%, and the description compensates for the weakest points: it specifies the edge id syntax and source (find_geometry kind=edges) and, most valuably, explains tangent_chain's behavior with the concrete full-circle-is-two-arcs example. "Constant-radius" clarifies that radius is a single uniform value. feature_name and the name pattern's lowercase/no-.prt rule are covered only by the schema, leaving a small gap.

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 core sentence — "Constant-radius round on the listed edges (edge:N ids from find_geometry kind=edges)" — names a specific verb (round) and resource (edges) and implies the contrast with sibling chamfer/shell. However, it is buried after three sentences of family-wide preamble (mirror tool, units, axes, save semantics), so an agent must read past unrelated context before learning what this tool does.

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?

It explicitly routes the agent to find_geometry kind=edges to obtain edge ids, and states the selection rule "list every edge to round, or pass tangent_chain=true" with the failure case (rounding one half of a circle alone fails). It also warns there is no mirror tool, directing symmetric work to extrudes/revolves/patterns. What it lacks is an explicit when-to-use-this-vs-chamfer statement.

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