character_pose

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description usefully confirms Joint transforms are read-only and that Point targets are read exhaustively. It adds nothing about the frame semantics (current frame vs. defaults when frame is omitted) or whether missing character raises an error, which matters given every parameter is optional.

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?

A single front-loaded sentence with an action verb and no filler. It is slightly dense, since "every native Point target and optional read-only Joint transforms" is ambiguous as to whether the joint state is itself optional or the target set is.

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 three-parameter read tool with no output schema, the description should say what the returned data looks like and how the frame default resolves; it sketches the returned content but never explains the default frame or the character identifier format. Annotations cover the read-only profile, so the remaining gap is moderate rather than severe.

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% for three parameters, so the description must carry the meaning. "for one RigInfo character" loosely maps to character (but gives no name/ID format), and "optional read-only Joint transforms" maps to include_joint_state, yet the frame parameter is never mentioned — no default, no current-frame behavior — leaving a real 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?

Specific verb ("Read") and a concrete resource: native Point targets plus optional Joint transforms for one RigInfo character. It gives an agent a clear idea of what comes back, but never distinguishes itself from the many other read-pose siblings (pose_read, rig_pose_read, semantic_pose_read, subtrees_pose_read), so differentiation is inferred only from the word "native Point".

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?

No when-to-use guidance at all; it does not say when to pick this over pose_read, rig_pose_read, semantic_pose_read, or character_pose_snapshot, nor whether a character/rig must be configured first. The only implied condition is "for one RigInfo character", which is not an alternative-selection rule.

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