Sheet Base

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the full burden — and it delivers rich behavioral disclosure: arcs are rejected rather than silently faceted, bends grow OUTWARD from the profile boundary, unfolding is a property of the feature tree rather than the fused solid, a part reopened from disk becomes a solid, and boolean_op cut keeps it a sheet part while fusing arbitrary material does not. These are substantial behaviors far beyond what annotations convey.

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 description is long but every section earns its place — parameter semantics, the critical tangent-to-tangent caveat with a concrete worked example (U-channel 100 mm/92 mm), and the feature-tree persistence caveat. It is front-loaded with the core purpose before diving into details. Slightly verbose in places, but the length is justified by the conceptual complexity of sheet-metal semantics.

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?

Given 0% schema coverage and no output schema, the description fully carries the burden and covers everything an agent needs: distinct profile vs sketch input modes, material corpus behavior, the tangent-to-tangent dimensiongotcha, the persistence/identity caveat, and the exact return object {handle, name, volume, thickness_mm, material, profile, area_mm2}. Nothing required for correct invocation is missing.

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 schema description coverage at 0%, the description must compensate, and it does so for the meaningful parameters: profile is defined as '[[x, y], ...] in the XY plane, implicitly closed'; sketch as an alternative 'closed, planar, straight-sided sketch on any plane'; material as any Materials-DB name that 'selects the K-factor and minimum-bend-radius'; and thickness_mm is tied to the extrusion. Only the trivial `name` parameter (default 'SheetBase') is left undocumented, which is minor.

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 opening sentence states the specific verb and resource ('Start a sheet-metal part: the base flange...extruded to thickness_mm') and explicitly distinguishes this foundational operation from the rest of the family by stating 'Everything else (flanges, tabs, hems, the flat pattern, the DXF) hangs off the handle this returns.' This tells an agent exactly what the tool is for and how it differs from siblings like sheet_flange, sheet_tab, and sheet_hem.

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 establishes clear context that this is the entry-point/starting operation ('everything else hangs off the handle this returns') and gives important selection constraints — that arcs are rejected rather than faceted, and that the profile is tangent-to-tangent, not the outside dimension. It lacks an explicit 'use X instead of this when Y' exclusion statement, but the positioning as the first sheet-metal operation is unambiguous given the sibling set.

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