plasticity_loft_curves

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

With destructiveHint=true and readOnlyHint=false already given, the description still adds meaningful behavior: the result is never joined to source bodies, profiles and guides are preserved, and the caller should verify the returned Sheet's topology and bounds. It does not cover failure modes (e.g., non-intersecting guides) or whether the operation is reversible/undoable.

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, no filler, front-loaded with the create action and followed by constraints, shape controls, and result caveats in a logical order. Slightly dense and could be split, but every sentence carries distinct information.

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 an 11-parameter, no-output-schema modeling operation, the description covers the core geometry semantics and the non-joining guarantee, but leaves roughly half the parameters (simplify, trims, revision, intent) unexplained and gives no pagination/return-shape detail beyond 'verify the returned Sheet topology and bounds'.

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 description coverage is 0% across 11 parameters, so the description carries the burden. It does clarify profileIds ordering, guideIds intersection requirements, closed-mode profile count, curvature enum values, and that start/end magnitudes are positive and dimensionless, but simplify, trimGuides, trimProfiles, revision, and intent are never addressed.

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 ('Create one independent native loft surface through an ordered list of current Wire profiles'), which cleanly separates it from the neighboring plasticity_loft_regions and plasticity_loft_faces that operate on regions/faces rather than Wire profiles. The 'independent', 'native', and 'preserving every profile and guide' qualifiers further pin down the produced geometry.

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 description supplies conditions and constraints (guides must intersect every profile; closed mode needs at least three profiles) but never states when to choose this tool over siblings like loft_regions, loft_faces, or bridge_surface. Usage is implied by the input type rather than explicitly routed.

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