lathe

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

With annotations already declaring this a non-destructive write (readOnlyHint=false, destructiveHint=false), the description usefully adds outcome behavior: close=true closes the loop into a ring, angle under 360 yields a wedge. It does not mention where the new object lands in the scene, whether it is undoable, or how it interacts with existing geometry, so it stops short of full transparency.

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 core action is front-loaded in the first sentence and the remaining sentences each add distinct shape/topology information without filler. It is dense but every clause earns its place; it could be tightened slightly but wastes little.

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, but the description compensates by enumerating the resulting geometry types. For an 8-parameter geometry-creation tool it is reasonably complete on the central concept, though it omits what `name`, `at`, `axis`, `cap`, and `segments` control and does not say it creates a new scene object.

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%, so the description must carry parameter meaning, and it does define `profile` (list of [radius, height] points bottom-up), `close`, and `angle`. It leaves name, at, axis, cap, and segments entirely unexplained, so over half the parameters remain opaque.

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?

"Spin a profile around an axis" gives a specific verb (spin/lathe) and resource (profile) and even enumerates the resulting shapes (vase, bottle, donut, wedge). It is clear what the tool produces, but it never contrasts itself with close siblings such as sweep, extrude_profile, or radial_array, so an agent gets no explicit disambiguation.

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 explains how profile topology maps to output (axis-touching = solid, off-axis = tube, angle < 360 = wedge), which implicitly guides usage. However, it never states when to choose lathe over sweep/extrude_profile/loft, nor any prerequisites or when-not-to-use conditions, so guidance is only implied.

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