destroy

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals that the operation is a physics simulation with Voronoi chunks, mentions that preview frames are returned, and explains the 'volume_kept' metric as a validity check. It does not explicitly state side effects like irreversibility or whether the original mesh is preserved, but the name 'destroy' plus the physics description convey the core behavior.

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 compact list of parameter explanations, which is appropriate for a tool with 23 parameters. However, it duplicates the English summary in Korean, wasting a sentence. Some entries could be integrated (density/friction/bounce are combined), but overall it is relatively tight for its size.

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?

The description covers the main purpose, result metric, and many parameter effects, but with no output schema, it should clarify all inputs and outputs. Six parameters are unexplained, and the description does not mention prerequisites, execution time, or scene side effects. For a complex 23-parameter tool, this is a notable gap, though the included notes on performance and physical correctness add value.

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 schema has 0% parameter description coverage, so the description must compensate. It explains 17 of 23 parameters, including enums, recommended ranges, and behavioral effects (e.g., 'impact_power: 충격체 무게 = 대상 전체 무게 × 이 값', pieces count affects speed). However, six parameters (dust, frames, seed, time_scale, impact_height, preview_frames) are left undocumented, and most explanations are in Korean, which may reduce accessibility for English-only agents.

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 action: 'Fracture any mesh into Voronoi chunks and collapse it with real physics.' This clearly distinguishes it from siblings like 'explode' or 'water' by specifying the Voronoi fragmentation and physics collapse. It also adds a scope note, 'Works on imported models,' which further narrows the resource type.

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 description provides no explicit guidance on when to use this tool versus alternatives such as 'explode' or 'reset_destroy'. It mentions 'Works on imported models' but that is a constraint, not a usage rule. There are no exclusions or alternative tool names, so the agent must infer usage context from the tool name alone.

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