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

Annotations already flag destructiveHint=true and non-idempotent behavior, so the safety bar is partly covered elsewhere. The description adds two genuinely useful traits beyond that: the motion is 'slowly' and the target is an 'operator-verified safe position'. It still omits the consequence of the destructive hint (crushing the grasped object), whether the call blocks until motion completes, and what happens if no verified safe position exists.

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 no filler. The one weakness is that 'operator-verified safe position' is dense but undefined, leaving ambiguity inside an otherwise tight sentence.

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 zero-argument action tool with no output schema, the annotations carry the safety profile, but the description should explain what closing implies (blocking motion, crush risk, unknown state if already closed). It covers the target and speed but leaves the agent guessing about the outcome of a destructive, open-world action.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The only semantics worth clarifying would be implicit inputs such as the safe pose source, which the description gestures at but does not define.

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 (close) and resource (gripper) plus a qualifier about the target position. It is distinguishable from open_gripper and cycle_gripper by the verb alone, though it never explicitly names or contrasts those siblings.

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 statement of when to prefer this over cycle_gripper or open_gripper, and no preconditions (e.g., object grasped, safe pose already recorded) are given. Usage must be inferred entirely from the name.

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

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

Annotations already flag this as destructive, non-idempotent and open-world, so the safety bar is lower; the description adds the useful detail that endpoints are operator-validated and calibrated. It says nothing, however, about what physical risk a 1-5 cycle burst carries, what happens on failure mid-cycle, or whether the gripper ends open or closed.

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?

One front-loaded sentence with zero filler; the range constraint sits right next to the parameter it constrains.

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 physical-motion tool with no output schema and an undocumented parameter, the description should disclose end state, failure behavior, or safety preconditions. The calibrated-endpoint note helps but leaves meaningful gaps.

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 parameter burden; it does supply the crucial 1-5 range that the schema lacks. It omits the unit of 'times' interpretation for an out-of-range value and any error behavior, so compensation is 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 compound verb and resource: opening then closing the gripper N times with calibrated endpoints. This clearly sets it apart from the single-shot open_gripper and close_gripper siblings by implication, though it never names them explicitly.

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?

The cycling use case is implied by 'a specified number of times', but there is no explicit guidance on when to prefer this over calling open_gripper/close_gripper repeatedly, nor any stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that no movement is commanded, which reinforces rather than duplicates the annotation, but it omits latency, whether it requires the robot to be enabled/calibrated, or error conditions.

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 zero filler; the key constraint (no movement) is stated immediately.

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 carries the burden of describing return values, and 'calibrated motor positions' is vague—no mention of units, per-joint structure, or freshness of the reading. Adequate but incomplete for a state-query 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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 read operation ('read calibrated motor positions') and the parenthetical 'no intentional movement' distinguishes it from the move_* siblings. It's clear what resource is accessed, though the exact return shape (joint angles vs. raw counts) isn't pinned down.

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?

The 'no intentional movement' note implies this is the passive/observation tool versus the move_joints and move_to_pose siblings, but it never explicitly says when to call it (e.g., before planning a motion) or that it should be used instead of motion commands for observation.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is partly covered. The description adds a useful safety constraint by stating it will only show pre-taught named poses and warns against guessing extreme poses, but it does not add details on permissions, limits, or return behavior beyond what the output schema provides.

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 two short sentences with no wasted words. The core purpose is front-loaded, and the safety warning follows immediately.

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 zero-parameter listing tool with annotations and an output schema, the description provides enough context to understand what is returned and why it is safe. It could be slightly richer by explicitly tying the tool to pre-motion checks, but it is largely complete.

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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with a no-argument listing tool.

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 uses a specific verb and resource: 'Show only pre-taught named poses.' It clearly distinguishes this listing tool from the move-oriented siblings by emphasizing pre-taught named poses, though it does not explicitly name an alternative tool.

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?

The clause 'Never guess an extreme pose' implies this tool should be used to retrieve safe, known poses before attempting motion. However, it does not explicitly state when to use this versus alternatives like move_to_pose or get_robot_state.

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

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

Annotations already flag this as destructive and non-idempotent, so the bar is lower, and the description still adds real value: the move is silently rejected if the target falls outside the limits in config.json, which is critical pre-call knowledge. It does not say what happens to prior state or how a rejected move is reported, but the key failure mode is disclosed.

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: the core behavior first, then a concrete example, then the failure constraint. No filler, and the most important information is front-loaded.

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 two-parameter tool with no output schema, the description covers purpose, an example, and the limits-based rejection behavior, which is enough to invoke it. The main omission is the set of valid joint identifiers, which an agent would otherwise have to discover by trial.

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 burden; it does supply a concrete joint value ("shoulder_pan") and the sign convention (negative pan = left), which is genuinely beyond the schema. However, it never enumerates valid joint names or clarifies units beyond the parameter name itself, leaving real gaps.

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?

Names a specific verb (rotate) and a precisely scoped resource (a single joint) and states that the motion is relative from the current position, which implicitly contrasts with the plural move_joints sibling. It stops short of naming the alternative tool, so the differentiation is inferred 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?

The example clarifies the intent of a relative move, but there is no explicit guidance on when to pick this over move_joints, move_to_pose, or get_robot_state first, nor any prerequisite such as needing the robot in a known state. Usage is implied rather than directed.

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

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

Goes meaningfully beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing atomicity ('otherwise nothing moves'), partial-update semantics ('joints not listed stay in place'), and an external precondition (limits live in config.json). It does not state what feedback or confirmation the caller receives after a successful move.

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?

Five short clauses, front-loaded with the core action and units, then example, defaults, constraint, and a safety exclusion. No repetition and nothing wasted.

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, non-idempotent mutation with a free-form object parameter and no output schema, the description covers units, partial-update behavior, atomic failure, and a safety precondition. Only the post-call feedback/success signal is unaddressed.

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 0% and the single 'targets' param is an open-ended nested object, so the description must carry the load — and it does: keys are joint names, values are degrees with gripper 0-100, a concrete example is given, unlisted joints are untouched, and every value must fall inside config.json limits. The one gap is that the agent cannot know those limits from the description itself.

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 and resource plus the operating mode: move one or more joints to ABSOLUTE positions, in degrees, with gripper on a 0-100 scale. The 'absolute' qualifier implicitly separates it from the near-named sibling move_joint_by (relative), but no sibling is named explicitly, so it stops short of a 5.

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?

Provides a clear when-not ('Do not use if work area is obstructed') and the absolute-vs-incremental framing that distinguishes it from move_joint_by. It still never names move_joint_by or move_to_pose as the alternative for a given situation, so routing is left partly to inference.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety bar is partly covered. The description adds real context beyond them: motion is slow, the pose is locally taught and verified safe, and it warns against use under obstruction. What's missing is reversibility/halt behavior and permission needs.

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?

Two tight sentences, the core action front-loaded and the safety caveat directly after. Every clause earns its place.

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 single-parameter tool with destructive annotations, the safety warning is present, but the description leaves the agent without a pointer to discover valid pose names (list_safe_poses is the obvious sibling), which is a meaningful gap for 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?

Schema coverage is 0%, so the description must carry the load. 'By name' signals the name refers to a taught pose, which adds meaning over the bare 'name' string, but it never says where valid names come from (e.g., list_safe_poses) or the accepted format.

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 (move) and resource (a taught safe pose identified by name), plus a speed/scope qualifier (slowly). It does not explicitly distinguish itself from the other motion siblings (move_joints, move_joint_by), but the 'safe pose by name' framing gives a clear functional identity.

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?

Provides one exclusion ('Do not use if work area is obstructed'), which is useful guidance. However, it offers no positive when-to-use condition and no routing versus move_joints or move_joint_by, so the agent must infer which motion tool to pick.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds nothing about the consequences — e.g. whether opening releases a grasped object, what force/limits apply, or what happens on repeat invocation. 'Slowly' is the only behavioral detail, which is thin for a destructive motion command.

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 no filler. It is efficient, though the vague term 'operator-verified safe position' consumes the one clause that could have carried operational meaning.

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 zero-parameter action with no output schema, this covers the basic action, but a destructive, non-idempotent motion command should disclose safety implications (dropped payloads, prior state requirements). The description leaves the agent unable to judge consequences before invoking.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4.

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 and resource ('open gripper') and adds a target qualifier ('operator-verified safe position'), which distinguishes it from close_gripper and cycle_gripper. The concept of 'operator-verified safe position' is never defined, so the destination remains ambiguous.

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 guidance on when to use this instead of close_gripper or cycle_gripper, nor any precondition (e.g. whether an operator must have verified the pose first, or whether the gripper must be holding something). The only hint of usage is buried in the phrase 'operator-verified', which is never explained.

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