plasticity_split_solid_by_plane

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

Annotations already declare destructiveHint=true and openWorldHint=false, but the description goes well beyond them: it explains the oversized B-Rep cutter derivation, the volume-conservation verification, the unrelated-body check, the removal of temporary cutter geometry, and that the operation consumes four native history steps. That history/cleanup/verification detail is exactly the kind of behavior an agent cannot infer from the annotations.

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?

Roughly four dense sentences, front-loaded with the operation and its guarantee, with the joint caveat placed after. Nearly every clause carries information, though the verification/cleanup sentence could be tightened slightly.

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 destructive, no-output-schema tool, the description covers mechanism, verification, and side effects well, but never indicates what the caller receives (e.g., new body identifiers or a success/failure status) or what a failed volume-tolerance check yields. That return-value gap is the main incompleteness.

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 compensate, and it partially does by defining units for three parameters ('plane origin, normal, and in-plane x direction are millimeters/world vectors'). It says nothing about targetId, revision, or the intent string, so half the parameters remain unexplained beyond their names.

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 first sentence states a precise verb+resource+scope: split one current Solid into exactly two native Solid parts with one explicit plane crossing its interior. The phrase 'one explicit plane' implicitly distinguishes it from the plural sibling plasticity_split_solid_by_planes, and the tool's mechanism (oversized planar cutter from B-Rep bounds) is unambiguous.

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?

It usefully clarifies the downstream workflow ('does not add an assembly joint; create a locating-pin or tongue-and-groove joint afterward'), which tells the agent this is a geometric split, not a joint. However, it never states when to choose this single-plane tool over the plural plasticity_split_solid_by_planes or plasticity_split_solid_to_build_volume, leaving alternative selection to inference.

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