Adds draft angles to selected faces around a neutral face for moulding, casting, and easier 3D-print removal.
Add draft to faces (moulding, casting, easier 3D-print removal).
| Name | Required | Description | Default |
|---|---|---|---|
| doc | No | Document title or path. Defaults to the active document. | |
| flip | No | ||
| name | No | Optional name for the new feature. | |
| angle | Yes | Draft angle in degrees. | |
| face_points | Yes | Faces to tilt. | |
| neutral_face_point | Yes | The neutral face (e.g. the parting/bottom face). |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive mutation, and the description adds nothing beyond that safety profile. It doesn't say a new feature is created in the feature tree, that the target document must be active or specified via 'doc', or what happens on invalid geometry.
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?
A single front-loaded sentence with the purpose followed by an immediately useful use-case gloss. It is efficient, though the parenthetical substitutes for rather than supplements behavioral detail.
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 6-parameter feature-creation tool with no output schema, the schema covers most parameters well, but the description leaves gaps around the 'flip' direction parameter and the document/feature-tree effects of the operation. It is minimally sufficient rather than complete.
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 83%, so the schema already explains angle range, face_points, neutral_face_point, and name. The description contributes no parameter-level meaning (e.g. what 'flip' toggles), so baseline 3 is appropriate.
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+resource ('Add draft to faces') and clarifies the domain purpose with the parenthetical about moulding/casting/3D-print removal. It is unambiguous what the tool does, though no sibling is named because no other draft tool exists.
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 parenthetical hints at when this applies (moulding, casting, print removal), which is implied usage context. There are no explicit when-not conditions, prerequisites (e.g. an open document with solid bodies), or named alternatives among the many feature tools like sw_shell or sw_thicken.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.