rename_anim_curve

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

Annotations already declare destructive=true, readOnly=false and idempotent=false, so the safety profile is covered. The description goes well beyond that, disclosing the single undo step, the exact error conditions (missing source curve, refused rename), the same-name no-op semantics with renamed=false/saved=false and nothing written, the curve_type fallback rule, and that a failed save yields success=false with saved=false plus save_error.

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?

Purpose and undo behavior are front-loaded, and every clause carries information (no-op case, error cases, save failure). It is slightly bloated by restating the return contract in prose and then again in a 'Returns:' line, and the third sentence is a dense run-on.

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?

With no output schema, the description correctly supplies the return shape and enumerates the non-obvious outcomes (no-op, refused rename, save failure). It does not say what happens to the renamed curve's keys/comments or whether the containing package is left dirty on a partial failure, which are the remaining gaps for a destructive 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 a baseline of 3 applies. The description earns above baseline by clarifying the curve_type semantics beyond the schema's terse 'float (default) or transform' – any value other than transform is treated as float – and by tying old_curve_name validity to the missing-source-curve error path.

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 specific verb (Rename), a specific resource (a float or transform curve), and the exact owning asset type (UAnimSequence), plus the mechanism (through its data controller). That is enough to separate it from the many other rename_* siblings (rename_bone, rename_curve_table_row, rename_pose_in_pose_asset) without opening any schema.

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?

Usage is implied rather than prescribed: the description explains failure when the source curve does not exist and the no-op case when old and new names match, which implicitly signals prerequisites. It never names an alternative (e.g. get_anim_curve_names for discovery, add_anim_float_curve or remove_anim_curve for other edits) or states when not to use this tool.

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