plasticity_create_tangent_circle

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

Annotations only provide the safety profile (readOnlyHint=false, openWorldHint=false, destructiveHint=true); the description adds substantive behavior: solutionPointMm is a disambiguator rather than a constraint, world-space input requires the sketch-plane normal while plane-local input inherits the referenced construction plane, and both source Wires remain unchanged. The 'sources unchanged' claim sits in mild tension with destructiveHint=true, but creating new geometry still mutates document state, so this is not a hard contradiction.

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?

Four sentences, none wasted, with the core action front-loaded before the prerequisite and parameter semantics. It is dense with unexplained domain jargon ('native circle', capitalized 'Wire segments'), which slightly raises the reading cost, but there is 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?

For a geometry-creation tool with no output schema, the description covers the construction rule, the sequencing prerequisite, solution selection, coordinate-frame handling, and non-destructiveness of inputs. What it omits is what the call produces (new curve/body identity) and failure behavior, though the absence of an output schema limits how much can reasonably be expected.

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?

With a zero-parameter schema the baseline is 4, and the description does real work here: it explains that solutionPointMm selects among multiple possible circle centers and is 'not an additional geometric constraint', and it clarifies the world-space vs plane-local coordinate-frame requirement. The only gap is that the schema object is empty even though the description references inputs, so the documentation is not backed by declared properties.

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 names a specific verb, resource and construction rule: create one fixed-radius native circle tangent to two current Wire segments. This distinguishes it from the sibling circle tools (create_circle, create_two_point_circle, create_three_point_circle) and from create_tangent_arc without opening any schema.

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 gives a concrete prerequisite sequence ('Use plasticity_list_curve_directions immediately before this call'), which tells the agent when in a workflow to invoke it. It does not, however, state when NOT to use it or name a competing sibling (e.g. a tangent-arc route), so it stops short of full alternative routing.

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