Split a mesh object into multiple parts by loose geometry or material slots. Use this to separate connected components or partition by assigned materials.
Split one mesh object into several.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | LOOSE splits disconnected shells; MATERIAL splits by material slot | LOOSE |
| name | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'split', implying a destructive modification of the mesh, but does not clarify whether the original object is removed, how resulting objects are named, whether the operation is undoable, or any prerequisites. The schema's mode descriptions add some behavior context, but the description itself is very sparse.
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 a single, front-loaded sentence that is efficient and easy to parse. It earns its place by stating the core action, but it sacrifices necessary detail about behavior and parameters, making it concise but not sufficiently informative.
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 mesh mutation tool with no annotations, no output schema, and two parameters, the description is incomplete. It does not explain the implications of the mode parameter, the side effects on the original object, or the expected outcome, leaving the agent to guess or inspect the schema for critical details needed to invoke 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?
The description adds no parameter-related meaning. The schema provides a description for the 'mode' parameter, but the 'name' parameter is only given a title with no explanation. Since schema description coverage is only 50%, the description should compensate for the missing 'name' semantics, but it does not.
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 description clearly states the action ('Split') and resource ('one mesh object') with an implied result ('several'). It is distinguishable from siblings like join_objects, which is the inverse operation. However, it does not mention the mode parameter or the specific types of splitting, so it is clear but not fully comprehensive.
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 is provided on when to use this tool, how to choose between LOOSE and MATERIAL modes, or how it relates to alternatives like join_objects or other mesh operations. The agent must infer usage solely from the tool name and the mode descriptions in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.