bind

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

Annotations declare destructiveHint=true but say nothing about what is destroyed; the description supplies that by stating existing same-named groups are overwritten. It also discloses the auto→proximity fallback and the relative performance of each method. It still doesn't state permission/context requirements or whether non-matching groups are preserved.

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-loads the action, then the concrete effects, then method trade-offs, then overwrite semantics, then workflow pointers. Dense but each clause adds information; the parenthetical semicolon style is slightly heavy but not wasteful.

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 this covers the essential agent needs: what it mutates, what it overwrites, method choice, and how to verify the result. Missing only finer details such as context/selection requirements and treatment of pre-existing groups that don't share bone names.

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 0%, so the description carries the burden, and it meaningfully explains three of five parameters: the two method enum values with their trade-offs, max_influences as the influence cap, and falloff as a power exponent. 'meshes' and 'armature' are only implied by the opening sentence rather than defined (e.g. name references), leaving a small gap.

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?

Opens with a specific verb+resource ('Skin meshes to an armature') and immediately enumerates the concrete effects (vertex group per bone, Armature modifier, parent). This distinguishes it from siblings like parent, attach, and transfer_weights, which an agent could otherwise confuse it with.

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?

Gives method-selection guidance with conditions: 'proximity' for fast/stylised low-poly, 'auto' for clean meshes with a proximity fallback. It also routes the agent downstream ('Check with check_weights, then try poses with pose_sheet'). No explicit when-not-to-use or prerequisites (e.g. selection/context requirements) are stated, so it stops short of a 5.

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