prepare_unreal_handoff

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

Annotations already declare a non-read-only, non-destructive, non-open-world operation, so the safety profile is covered. The description adds real behavioral context beyond that: the editor validates the exact project and matching rig hierarchy before creating an asset, implying failure modes around mismatched rigs. It does not say whether a preparation record persists or how failures are surfaced, keeping it below a 5.

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?

Three short sentences, front-loaded with the action, then the validation caveat, then the ordering instruction. Little waste, though the validation sentence is slightly oblique about whether failure occurs at prepare time or at import time.

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?

An output schema exists, so return values need not be explained, and the nested UnrealTarget fields are typed in the schema. However, for a five-parameter tool with zero schema description coverage, the meaningful gaps (source_kind semantics, attempt/sample_index purpose, cross-field constraints on the rig paths) leave an agent guessing on non-trivial inputs.

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 description coverage is 0% and the description explains none of the five parameters. Most notably, the 'source_kind' enum (skeleton vs character) is central to the animation-only distinction yet is never mentioned, and 'attempt' and 'sample_index' — both bounded, retry-like parameters — are entirely undocumented.

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 gives a specific verb and resource ('Prepare animation-only Unreal import') and scopes it to animation-only, which separates it from the character-handoff siblings. It also distinguishes itself from execute_unreal_handoff by naming the handoff execution step, though it never explicitly contrasts with prepare_character_handoff / prepare_blender_handoff.

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?

It states a concrete precondition ('after Blender reports a verified FBX export') and an explicit ordering rule ('Import the rigged character mesh first, then use execute_unreal_handoff'), which effectively routes the agent between prepare and execute. It stops short of saying when *not* to use it or how it relates to the sibling prepare_* variants.

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