set_hand_pose_sequence

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

Annotations already declare the write/destructive profile (readOnlyHint=false, destructiveHint=true), so the description is not obligated to restate that. It adds genuinely useful context beyond the annotations: atomicity ('one checked native transaction'), non-destructive scope ('preserves existing body keys and interpolation'), and the async read-back pattern ('read back after timeout'). It could say more about failure behavior, but the added behavioral detail is real.

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 dense sentences that front-load the verb and scope, then the constraints, then the read-back note. Little wasted text, though the jargon ('Cascy finger chains', 'checked native transaction') trades clarity for brevity.

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, deeply nested, no-output-schema tool this covers the essentials: what is written, atomicity, what is preserved, and how to confirm via read-back. Missing are failure/rollback semantics and why the read-back is time-delayed, but overall it is complete enough to invoke correctly.

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%, so the description must carry the load. It does clarify the semantic meaning of the poses payload (finger local unit quaternions, 1-8 frames, left/right, validated finger chains) that the bare number-array schema cannot convey. But scene_id and character_id are never explained, so compensation is only partial.

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 (Write) and resource (1-8 frames of semantic left/right finger local unit quaternions) in one sentence, and the clause 'not body joints' begins to differentiate it from the body-pose siblings like set_pose_sequence/set_semantic_pose. It never names a sibling explicitly, so differentiation is implied rather than stated.

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?

'Only validated Cascy finger chains, not body joints' gives an implicit when-not condition, steering the agent away from body-joint use. However, no alternative tool is named and there is no explicit guidance on when to prefer this over set_pose_sequence, set_semantic_pose, or set_pose_snapshot.

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