rhino_mesh_split

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

No annotations exist, so the description carries the full burden. It discloses only the basic operation; it does not say whether the original mesh is modified, whether new objects are created, how the mesh/surface operands are chosen, or whether any undo/safety implications apply.

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 sentence is short and front-loaded with the action. The Args block is unnecessary boilerplate but does not meaningfully hurt clarity.

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 mutating mesh operation with zero annotations and a complex family of sibling split/boolean tools, the description omits selection requirements, output behavior, and edge cases. An agent knows what the tool does conceptually but not how to invoke it correctly in the current Rhino session.

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?

The input schema declares zero parameters, so there are no parameter semantics to document; baseline 4 applies. The 'Args: controller' line is a runtime detail rather than a user-facing parameter and does not add useful schema-level meaning.

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?

Description states a specific verb and resource ('Split a mesh with another mesh or surface'). It is clear what class of operation this is, though it does not differentiate from sibling tools like rhino_split, rhino_mesh_trim, or rhino_boolean_split.

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?

No guidance about when to choose this tool over the many other split/trim/boolean siblings, and no mention of prerequisites such as pre-selecting the target mesh and cutter. The expected usage context must be inferred from the name.

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