body_split_face

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

No annotations are provided, so the description carries the full burden, and it does: it names error codes and their causes (INVALID_PARAMS with no change, FUSION_API_ERROR for unsupported split types), gives the default of extend_tool, and enumerates the returned keys including health and created/modified/removed bodies. This is well beyond a bare purpose statement.

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?

Front-loaded purpose, then a compact mode list, a refs line, an errors line, a return shape, and one concrete example — every line carries distinct information with no filler.

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 5-parameter mutation tool with no annotations and no output schema, the description covers what it does, valid inputs, failure modes, and the return payload, which is everything an agent needs to call it correctly.

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 coverage is 100%, so the baseline is 3, but the description adds the cross-parameter constraint (along_vector requires direction; direction with any other type is an error) and clarifies extend_tool's role in relation to the tool. Marginal gain is real, though the per-parameter meanings themselves are already in the schema.

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 ('Split faces of a body with a tool') plus the reason (separate faces for draft, offset, colors), which distinguishes it from body_split, body_delete_faces, or surface_trim. An agent can tell what it produces — new faces — without opening anything.

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?

Explains the three split modes (intersection along the tool, along_vector projecting along direction, closest_point) and where to obtain valid refs (inspect_query, origin:*/construction_*, sketch_* results). It doesn't explicitly route the agent between this and body_split or body_delete_faces when the goal is ambiguous, but the operational conditions for each mode are clear.

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