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

With no annotations, the description carries the full disclosure burden. It reveals useful behaviors: parts keep their last pose until moved again, and frames are 0.25 s apart. It does not, however, disclose whether setting a pose overwrites existing keyframes, what happens on invalid input, or the result of the operation—important gaps for a mutation tool.

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?

The description is compact (about 60 words) and front-loaded with the scope, followed by usage modes and a behavioral note. Every sentence adds value, and the moves definition is placed at the end for reference. There is no filler or unnecessary repetition of schema details.

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?

Given the tool's moderate complexity (4 params, no output schema, no annotations), the description covers the core usage: allowed frame range, single vs. multiple frame invocation, and pose persistence. It does not specify units for position/rotation, whether frame and moves are both required, or error conditions, but the schema's examples partially fill the gap. Overall it is sufficient for a basic correct invocation.

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?

The schema covers forge_handle and gives examples for moves and frames, but the description adds critical meaning: the valid frame range (1 to max_frames: 16, 32, or 48), and the exact structure of moves ('moves = {part_id: {position?, rotation?}}'). It also clarifies that frames is an alternative to frame + moves, which is not fully evident from the schema's brief text.

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 opens with a clear scope ('Animated trials only') and specifies the action: 'set the pose of some parts at one frame' or multiple frames via the 'frames' parameter. It distinguishes this tool from siblings like forge_add/forge_edit by focusing on keyframe placement, and it gives concrete constraints (campaign sizes, frame limits) that make its purpose unambiguous.

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 clearly states the applicable context—animated trials only—and explains the two invocation modes (single frame vs. multiple frames) along with a behavioral rule about pose persistence. However, it does not explicitly name alternative tools for non-animated cases or state when not to use this tool, though the sibling list is self-explanatory in context.

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