plasticity_deform_curves_between_faces

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

Annotations only say readOnlyHint=false and destructiveHint=false. The description goes beyond them by stating that source Wires and both reference-face bodies are preserved, that the output is independent copies rather than an in-place edit, and that deformation intentionally changes geometry. This is meaningful added context, though it omits revision/transaction semantics and any error conditions.

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?

Three tight sentences, front-loaded with the core action, then the preservation guarantee, then the numeric-control and verification notes. No filler, though the final clause about returned points/tangents/lengths/bounds is slightly list-heavy.

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, nested-object mutation with no output schema, the description does useful work by naming what the return inspection should cover (exact curve points, tangents, lengths, bounds). It still leaves the required inputs and the revision/intent parameters unexplained, and gives no failure or rollback context.

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 must carry the load. It does explain the intent of scaleU/scaleV/scaleNormal as dimensionless native mapping controls and groups flipUV/mirror/flipNormal as orientation flags, which covers roughly half the parameters. It says nothing about the required ids, sourceFace/targetFace structure, revision, or intent parameters.

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 independent native Wire copies by mapping selected curves from one exact source face onto a different exact target face'), which is clear and actionable. It implicitly distinguishes itself from the curve-creation siblings by operating on existing faces, but it never names the closest sibling plasticity_deform_bodies_between_faces, so an agent must infer the split between curve-deform and body-deform.

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?

There is no explicit when-to-use guidance, no prerequisites (e.g. that source and target faces must already exist in the document), and no named alternative for the curve-vs-body deform decision. The only actionable instruction is to inspect the result afterwards, which is verification advice rather than selection guidance.

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