rename_pose_in_pose_asset

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

With destructiveHint=true already set, the description still adds substantial value: it runs inside an undo transaction and saves, distinguishes three error cases (unknown old name, duplicate new name, engine-rejected rename) as 'nothing saved', and specifies the same-name edge case as success with renamed=false and saved=false. Failed-save semantics (saved=false, save_error) are also made explicit.

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-loaded with the core action and engine call, then the error/edge-case clauses. Slightly repetitive ('nothing saved' / 'nothing is modified or saved') and dense, but every clause carries decision-relevant information.

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?

No output schema exists, and the description compensates by enumerating the full return object (renamed, contains_new, contains_old, num_poses, pose_names, saved, save_error, message). Combined with the safety annotations, an agent has everything needed to call and interpret this mutation tool.

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 100%, so baseline is 3, but the description adds real meaning beyond the schema's terse strings: it defines how old_pose_name and new_pose_name interact (unknown, duplicate, and identical values each produce distinct outcomes). This is genuine parameter behavior guidance, not restatement.

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?

States a precise verb+resource: rename an existing named pose in a UPoseAsset, even citing the engine function UPoseAsset::ModifyPoseName. This cleanly separates it from sibling pose-asset tools (add_pose_to_pose_asset, remove_pose_from_pose_asset) and from the many rename_* tools that target different resources.

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 thoroughly covers the outcomes of calling it, but never states when an agent should prefer it over siblings like remove_pose_from_pose_asset or create_pose_asset, nor any prerequisite conditions. Usage is strongly implied by the rename semantics but not contrasted against alternatives.

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