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

Annotations already declare it safe, idempotent and read-only, so the description's value is in the extra behavior it discloses: images wider than the policy's max_image_width are downscaled, and the call is refused outright if Pillow is unavailable. That is a genuinely non-obvious failure mode an agent could not infer from the schema or annotations.

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 return shape, then the size caveat. No filler and every sentence carries information the agent needs.

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?

There is no output schema, and the description compensates by describing the return as an image plus JSON metadata (width, height, stamp). Combined with the downscale/refusal caveat, an agent knows what it will get and what can go wrong; only the behavior on a stale or unavailable topic is unstated.

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 parameter meaning, and it does: 'topic' is constrained to an allowlisted camera topic and the agent is told exactly where to look it up (get_safety_envelope.camera_topics). It doesn't specify the string format of a topic name, which would have earned a 5.

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 ('Grab the latest image from an allowlisted camera topic') and clarifies the scope constraint (allowlist). No sibling tool fetches camera imagery, and the description points to get_safety_envelope for valid topics, so an agent can place it precisely.

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?

Gives clear context for use by naming the prerequisite — the topic must come from the allowlist returned by get_safety_envelope.camera_topics. It doesn't state when not to use it or name an alternative, but for a read-only snapshot there is no competing sibling.

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 it is a non-read-only, non-idempotent, non-destructive, open-world operation. The description adds critical behavioral context beyond the annotations: it may require human approval and is refused under an active software e-stop.

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 concise sentences, front-loaded with the primary action and immediately followed by the key approval and e-stop preconditions. No unnecessary repetition.

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 parameters, an existing output schema, and annotations covering the mutation safety profile, the description supplies the remaining operational context: purpose, approval possibility, and e-stop interlock. Nothing essential for correct invocation is missing.

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 are no parameter semantics to explain. Per the rubric, a zero-parameter tool has a baseline of 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: "Clear the robot's error/reflex state," with a concrete example (collision reflex). It also distinguishes itself from e-stop reset by noting it is refused while the software e-stop is active and that reset must happen first.

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?

Explicitly says when to use it (after a collision reflex) and when it will not work (while the software e-stop is active), and points to the prerequisite action (reset e-stop first). The human approval caveat further clarifies invocation conditions.

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 well past the annotations: it discloses what is destroyed (all plans invalidated), what is blocked afterwards (motion/gripper/control tools), the reset condition (human approves reset_estop), and runtime traits (always available, no rate limit, no approval). It also flags the hardware-e-stop boundary, which annotations cannot express.

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 tight sentences: the action first, then the consequences and gating, then the safety caveat. No filler and nothing redundant.

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 no explanation, and the description covers consequences, availability, and the reset path. An agent has everything needed to invoke this correctly under pressure.

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 single parameter has 100% schema description coverage, so the schema already explains 'reason' and its audience. The description only adds that any reason is accepted, which is marginal over structured data — baseline 3.

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 action with an explicit blast radius: stop all arm and gripper motion, invalidate every plan, and refuse motion/gripper/control tools until reset. That effect profile is distinguishable from stop_motion and the other siblings without opening a schema.

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 makes clear this is the unconditional, always-available safety action, names reset_estop as the human-gated exit path, and warns it is not a substitute for the hardware e-stop. It does not explicitly say when to prefer it over stop_motion, but the described scope implies the answer.

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 far beyond the annotations: re-validation against the safety envelope, rejection of stale/used handles, possible human approval gate, live force monitoring with a latching e-stop, progress streaming, single-use handles and serialized execution. Annotations already flag destructive/non-idempotent, and the description adds the concrete consequences behind those hints.

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?

Front-loads the action and stays dense, with each clause covering a distinct behavior (validation, approval, force guard, cancel, dry-run). The middle sentence is packed with many clauses and could be split for readability, but little is 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 potentially destructive, open-world motion tool with one parameter, the description covers safety gating, refusal conditions, cancellation semantics, and dry-run behavior. An output schema exists, so return-value detail is correctly omitted.

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 only parameter is fully documented in the schema (plan_id returned by a plan_* tool), so the baseline is 3. The description adds real semantics on top: the handle is single-use and rejected if stale, expired, or already used, which affects how an agent must manage the value.

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?

Opens with a specific verb in caps plus the resource and scope: 'EXECUTE a previously planned motion on the robot.' This clearly separates it from the plan_* siblings that create plans and from stop_motion/estop that halt motion.

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?

States the precondition (a plan returned by plan_* tools), the single-use/one-at-a-time constraint, and when the call will be refused (stale, expired, used, or no force estimate). It stops short of explicitly routing to stop_motion/estop for the abort case, so there is no full alternative comparison.

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, idempotentHint, destructiveHint and openWorldHint, so safety and side effects are covered, and the description adds real value with 'Images are redacted' — a privacy behavior an agent could not otherwise know. However, it does not disclose ordering (newest-first?) or whether the tail is truncated, which are the remaining behavioral unknowns for a tail-read.

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 short sentences, zero filler, and the scope-and-content clause is front-loaded ahead of the redaction caveat. 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?

An output schema exists, so return-value shape need not be explained, and the parameter is constrained by the schema. What remains missing is the ordering/truncation behavior and whether the log is global or session-scoped — minor but relevant for a read-only audit 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?

Schema description coverage is 0%, so the description has to carry semantics for the single parameter, and 'the last n' does add meaning the schema lacks: it establishes that n counts events and that the window is the most recent ones. The bounds (1-200, default 20) are covered by the schema 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?

The definition names the specific resource (audit-log events) and enumerates the event types it contains (tool calls, approvals, denials, e-stops), which lets an agent tell it apart from the robot-state and safety siblings. It is a noun phrase rather than a verb+resource construction, but the resource and scope are 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?

The description only defines what the tool returns; it gives no explicit when-to-use statement, no mention of when another tool (e.g. get_safety_status or get_motion_status) would be preferable, and no prerequisites. Usage is left entirely to inference from the resource 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 declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds that progress is normalized 0..1 and that the last execution result is included, but doesn't say whether this is per-plan or global, whether status is transient/stale, or how to interpret a failed prior run.

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 compact sentence that front-loads the primary signal (is a plan executing) and then enumerates the secondary outputs. No waste, though the elliptical fragment style trades a little readability 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?

An output schema exists, so the return shape needn't be spelled out, and zero params keep the call surface trivial. What's missing is lifecycle context, such as when this is meaningful relative to execute_plan/stop_motion and whether the last-result field persists across unrelated runs.

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 4 applies. Schema coverage of 100% means no parameter gaps exist in either place.

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 what the tool reports: execution state, progress (0..1), and the last execution result for a plan. This is specific enough to separate it from siblings like get_robot_state or get_safety_status, though the verb is implicit (a fragment rather than 'Get...').

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 indication of when to call it or what it relates to (e.g., poll after execute_plan, check before stop_motion/error_recovery). The only hint about alternatives is the implicit contrast with the robot-state siblings, which the agent must infer.

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, idempotentHint, destructiveHint=false and openWorldHint, so the trailing 'Read-only.' is largely redundant. The useful additions are frame/unit details and the implied nature of the read (a live snapshot rather than a cached or historical value), though freshness, latency, and behavior when the controller is unreachable are not 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?

A single compact sentence-pair that front-loads the most important quantity and packs units and frames inline without padding. The closing 'Read-only.' repeats the annotations and is the one expendable phrase.

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 an output schema present, the description need only orient the agent, and the enumeration of joints, pose, wrench, gripper and safety does that well, including units and reference frame. A note on sampling time or staleness would close the remaining gap for a state-read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter explanation is possible or needed.

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 enumerates exactly what state is returned (joint positions with units, TCP pose with frame and quaternion order, wrench, gripper, safety) so the resource is unambiguous. It does not differentiate itself from overlapping siblings like get_motion_status or get_safety_status, which is the only thing keeping it below 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?

There is no statement of when to call this versus get_motion_status, get_safety_status, or get_safety_envelope, all of which plausibly surface overlapping information. The agent must infer usage purely from the field list.

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?

The annotations already establish read-only, idempotent, closed-world behavior, so the description's job is to add context, and it does: violations are rejected server-side and cannot be overridden. That enforcement note is exactly the kind of consequence an agent needs before planning. It omits whether the envelope is static or can change at runtime.

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 sentences, front-loaded with the resource and its contents, followed by the actionable constraint. The parenthetical enumeration is dense but each item is substantive rather than filler.

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 an output schema present, return values need not be explained, and the description covers purpose, contents, and enforcement consequences adequately. The one real gap is sibling disambiguation against get_safety_status, which an agent would need in order to pick the right 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?

The tool takes no parameters, so the baseline is 4 and there is no parameter semantics for the description to carry. The enumerated list of envelope contents usefully pre-describes what the zero-argument call returns.

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 names the specific resource and enumerates its contents (joint limits, workspace box, keep-out zones, speed/step caps, force thresholds, gripper limits, approval mode), so an agent knows exactly what it gets back. It does not, however, distinguish itself from the sibling get_safety_status, which an agent could reasonably confuse with this 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?

"Read this before planning and stay inside it" gives an explicit trigger and an explicit obligation, which is actionable guidance. It stops short of naming an alternative or exclusion — notably it never says how this differs from get_safety_status — so it is clear context without routing.

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 establish read-only, idempotent, non-destructive behavior, and the description usefully adds that the tool is never rate limited and that some violations are latched or historical. It does not state permission requirements or further operational caveats, so it is strong but not exhaustive beyond annotations.

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 a compact, front-loaded sentence that lists the key returned safety fields and appends the rate-limit note without waste.

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 zero parameters, an output schema, and annotations covering safety profile, the description supplies enough context for correct selection. It identifies the exact safety status contents and adds a useful operational note.

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?

There are zero parameters, so parameter semantics are inherently simple. The description does not need to explain argument meaning, and the baseline for a zero-parameter tool is appropriate.

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 names the specific safety data returned: E-stop state, latched force violation, dry-run flag, and last envelope violation. That makes the tool's purpose clear, though it does not explicitly distinguish it from related siblings like get_safety_envelope or get_robot_state.

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 description gives no explicit when-to-use guidance, prerequisites, or alternatives. It only lists what the tool reports, leaving the agent to infer that it should be called for safety checks.

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?

Adds real behavior beyond the annotations: the exact success predicate (fingers must settle inside the epsilon band, reported as ok=true) and the important non-obvious rule that over-max forces are rejected rather than clamped, which changes how a caller should retry. Annotations already flag destructive/non-idempotent/openWorld, so the remaining gap is the failure aftermath (is the gripper left closed on failure? is an error raised?).

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 tight sentences with zero filler; the action and its arguments come first, followed by the success criterion and the force-policy edge case in descending order of importance.

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 the ok=true return needs no further explanation, and annotations already carry the destructive/non-idempotent safety profile. What the agent actually needs to call this correctly — required width and force semantics, tolerance behavior, force rejection policy — is all present.

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 100%, so baseline is 3, but the description still earns a step: it explains how width_m and the two epsilon parameters combine into the acceptance interval, and clarifies that exceeding the force bound is a hard rejection (the schema only says 'must not exceed the policy maximum'). speed_mps is not mentioned at all in the description.

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 concrete verb and resource ('Close the gripper on an object') plus the two governing quantities (width_m, force_n), and adds the success predicate, so the tool's intent is unmistakable. It never names or contrasts with the nearby gripper_move / gripper_home siblings, so an agent must infer the split (grasp-with-force vs. positional move vs. homing).

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?

Usage is only implied: the success-band condition conveys 'use this when you know the object width and want a force-limited grasp', but there is no explicit when-to-use, no exclusions, and no pointer to gripper_move for plain positional commands or gripper_home for reset. The agent has to reason about the sibling family on its own.

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 openWorldHint=true; the description adds value by explaining that homing means fully opening and calibrating, which implicitly signals a held object could be released. It does not state blocking/time behavior, failure modes, or that calibration may require clear space.

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 sentence with no waste, front-loaded with the action and immediately qualified by the physical effect. 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?

With an output schema present and annotations carrying the safety profile, the description is nearly sufficient. However, for a destructive, non-idempotent actuation call, it should warn that a grasped object will be dropped and that the gripper must be unobstructed during calibration.

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 no parameter semantics to explain and the baseline of 4 applies. Nothing in the description contradicts the empty schema.

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 (Home) and resource (the gripper), and the parenthetical '(fully open and calibrate)' clarifies what homing physically means. It doesn't explicitly contrast with gripper_move or gripper_grasp, but the operation is distinct enough by name.

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?

There is no statement of when to call this versus gripper_move/gripper_grasp, no prerequisites (e.g., after power-on or error recovery), and no exclusions. 'Home' implies initialization usage, but the agent must infer it entirely.

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 the mutation profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), so the description only needs to add motion-specific behavior. It adds the useful no-force semantic, but says nothing about whether the move blocks until complete, what happens on collision or timeout, or why a simple width move is flagged destructive.

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 that carries the verb, the target, the unit, and the distinguishing constraint with zero filler.

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. However, for a physical-actuation tool whose annotations mark it destructive, the description leaves out blocking behavior, failure modes, and safety/collision considerations that an agent needs before invoking it.

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 100%: width_m's range and the optional speed_mps default are fully documented in the schema. The description only restates the unit-bearing target and adds no additional meaning about units, clamping, or what happens if speed is omitted.

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 (move gripper fingers) with the target quantity (opening width in meters) and the key differentiator from gripper_grasp: no grasp force applied. It does not explicitly name gripper_grasp or gripper_home, so sibling 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?

The phrase 'without applying grasp force' implies this is the positioning-only alternative to gripper_grasp, but the description never says when to use this instead of grasp or home, nor any prerequisite such as the robot being in a valid 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description's one added signal is the policy gate on which controllers may be switched, which is useful context for downstream switching, but nothing about cost, freshness, or 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?

It is short with no filler, but it is a noun-phrase fragment lacking a verb, so the key action is only recoverable from the tool name. Every word earns its place; the structure is the weakness, not the length.

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 an output schema present, the returned fields (type, state, switch permissions) need not be spelled out, and with 0 params the schema carries no burden. The remaining gap is guidance on sequencing relative to switch_controllers, which is left to inference.

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. The only thing it could clarify is whether the listing is filtered by namespace or policy, which it partially implies 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?

The description names the specific resource (ros2_control controllers) and what is returned about them: type, state, and policy-permitted switching. A fragment rather than a verb-led sentence, but an agent can still tell this is a read/list of controllers and infer it differs from switch_controllers.

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?

Usage is only implied: 'which ones the policy lets you switch' hints this is the discovery step before switch_controllers, but there is no explicit 'use before switching' or 'when not to use'. No alternatives or exclusions are named.

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, idempotentHint=true and destructiveHint=false, so the bar is lower, yet the description still adds a non-obvious scope constraint: this server cannot publish or invoke arbitrary services. That prevents a plausible agent error (assuming this tool could trigger ROS services) and is genuine value beyond the structured data. It does not discuss return shape or visibility edge cases (e.g. namespace filtering), which keeps 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?

Two short sentences with the resource enumeration front-loaded and the constraint appended, which is the right ordering. Nothing is wasted, though the wording is terse enough that a slightly more explicit verb ('Lists') would have cost no length and improved scanability.

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-value explanation is not required, and annotations cover the safety profile. The description supplies the resource scope plus the key capability limit, which is sufficient for an agent to call it correctly. Minor gap: no mention of whether results are filtered by namespace or refreshed live versus cached.

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 the baseline is 4 and there is nothing for the description to compensate for. Schema coverage is 100% and the empty argument object matches the description's implied no-arg invocation.

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 the specific resource (ROS 2 nodes, topics, services, actions) and the scope qualifier 'visible to the server', which tells the agent this is a discovery/listing operation. The verb is implicit from the name rather than stated, and there is no explicit differentiation from siblings like list_controllers or lookup_transform, though the resource is distinct enough to disambiguate in practice.

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 scope note 'visible to the server' and the read-only constraint imply this is the entry point for enumerating the ROS graph, so usage is inferable. However, there is no explicit 'use this when...' or 'use X instead' routing against siblings such as list_controllers or get_robot_state, which overlap conceptually.

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 readOnly, idempotent, non-destructive and openWorld, so the agent knows this is a safe, side-effect-free query. The description adds genuinely useful conventions beyond that — metres and quaternion order (x, y, z, w) — but says nothing about failure behavior (unknown/expired frame), whether the transform is the latest available or time-parameterized, or the tolerance for disconnected frames.

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 sentence, front-loaded with the core semantics, followed by the units and quaternion convention as a compact trailing clause. Nothing repeated from the schema and nothing extraneous.

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 two required parameters, annotation coverage, and an output schema that handles return-value documentation, the description is complete enough to call correctly. The only real gap is error/lookup-miss behavior, which matters for a ROS tf2 call but is not covered by the output schema.

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 burden, and it does: it defines the role of each parameter and supplies concrete example values, resolving the classic source-vs-target inversion. It stops short of stating whether frame names need a leading slash or how to reference a fixed world frame.

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 states a precise verb (express/look up) and resource (pose of source_frame in target_frame) with the tf2 semantics named explicitly, which pins down the direction of the transform — the exact thing that is ambiguous in frame math. No sibling tool performs a transform lookup, so an agent can route here unambiguously.

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?

Usage is implied rather than stated: an agent infers this is the tool to call when it needs a pose converted between frames, but there is no explicit 'use this when' clause, no mention of alternatives, and no note on preconditions such as the frames needing to exist in the ROS graph. Adequate but leaves the selection reasoning 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description goes further by disclosing the max_cartesian_step_m policy cap and that the returned plan is validated against the safety envelope. That is real behavioral context beyond the structured fields, though failure modes (unreachable waypoint, envelope violation) are not described.

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 sentences, zero filler, with the most decision-relevant constraint ('do NOT move') front-loaded before the path-length cap. 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?

An output schema exists, so the description need not explain return values, and it still signals that a validated plan summary is returned. The only meaningful gap is the missing hand-off to execute_plan and the absence of any note about what happens when the envelope check fails.

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 100%, so all four parameters (frame_id, waypoints, velocity/acceleration scaling) are already documented in the schema. The description only restates the [m] unit for waypoints and adds no format or constraint detail beyond the schema, so the baseline 3 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 verb ('Plan') and resource ('straight-line TCP path through the waypoints [m]') and immediately distinguishes the operation from its execution counterpart with '(do NOT move)'. An agent can tell this apart from execute_plan / plan_to_pose without opening any schema.

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 '(do NOT move)' parenthetical implies the plan-then-execute workflow, but the sibling that consumes the plan (execute_plan) is never named, and nothing says when to prefer this over plan_to_pose or plan_to_joints. Usage is only implied.

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?

Adds real context beyond the annotations: the plan is validated against the safety envelope, a plan summary with a status field is returned, and scaling above the policy cap is clamped rather than rejected. The readOnlyHint=true annotation aligns with "do NOT move", so no contradiction. It doesn't say what a 'rejected' status implies or whether plan_ids expire.

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?

Front-loads the critical constraint "(do NOT move)" and packs purpose, validation, next step, and clamping behavior into two tight sentences with no filler.

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?

Covers what the tool does, what it returns conceptually (plan summary + status), what to do next (plan_id to execute_plan), and edge-case behavior (clamping). With an output schema present, nothing material is left for the description to carry.

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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the clamping behavior when scaling exceeds the policy cap explains what actually happens at the boundary instead of just stating a max. It also reinforces the [rad] unit and current-state origin for joint_positions.

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 ("Plan ... a joint-space motion") and disambiguates from pose/Cartesian planning siblings via "joint-space" plus the explicit "do NOT move" scope limit. An agent can pick it apart from plan_to_pose and plan_cartesian_path without opening any schema.

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?

Gives a concrete workflow rule: if status is not 'rejected', pass plan_id to execute_plan — clear downstream handoff. It also implies what not to expect (this tool does not move the robot). It stops short of naming plan_to_pose/plan_cartesian_path as alternatives with a stated selection condition.

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 the description is consistent with that via '(do NOT move)'. It adds genuinely useful behavior beyond annotations: it uses inverse kinematics, the resulting path is joint-space interpolation so the TCP does not travel straight, and the plan is validated against the safety envelope. It stops short of describing failure modes such as unreachable goals or IK failure.

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 tight sentences, front-loaded with the action and its most important constraint ('do NOT move'), then the path caveat, then the return. No filler or repetition of the name.

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 an output schema covering the plan summary and annotations covering safety, the description supplies the remaining decision-critical context: path type, sibling routing, and safety validation. Nothing needed to invoke it correctly is missing.

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 100%, so every parameter (frame_id, position, orientation, velocity_scaling, acceleration_scaling) is already documented, including 'omit to keep current' for orientation. The description adds no further per-parameter semantics, so the baseline 3 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?

Specific verb (Plan) plus specific resource and scope (motion bringing the TCP to a pose), and it explicitly marks the boundary 'do NOT move'. It also names the sibling it is not (plan_cartesian_path), so an agent can tell them apart without opening either schema.

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 gives an explicit routing rule: use plan_cartesian_path when a straight-line TCP path is required, implying this tool is for redundant/IK-based goal-reaching plans. The '(do NOT move)' caveat steers the agent toward execute_plan for actual motion. It does not discuss plan_to_joints (joint-space goal vs Cartesian goal), leaving that comparison 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 declare non-read-only, non-idempotent, non-destructive, but the description adds the crucial fact that every call routes through human approval and that approvals are scoped to a single e-stop event. The only gap is behavior when no e-stop is latched (error vs. silent no-op), which matters for a non-idempotent 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?

Three short sentences, each doing distinct work: what it does, the approval invariant, and the retry edge case. The most important constraint (approval) is front-loaded before the edge case.

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?

Output schema exists, so return values need no explanation, and the safety-critical approval semantics are fully covered. The remaining hole is the failure/no-op case when nothing is latched, plus no explicit pointer to the `estop` sibling for the inverse operation.

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-parameter tool, so there is nothing to disambiguate; baseline applies. The description correctly implies the target state comes from the server's current latch rather than caller input.

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 (release) plus specific resource (the software e-stop and any latched force violation), which cleanly distinguishes it from the sibling `estop` that engages the stop. An agent can tell exactly what state change this performs.

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?

States the precondition (e-stop latched, including force violations), the mandatory human-approval gate regardless of approval mode, and an explicit re-invocation rule when a second e-stop latches while the prompt is open. That is unusually complete when/when-again guidance.

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 confirm this is a destructive action (destructiveHint: true) and that it is not idempotent. The description adds the constraint about policy maxima, which is important operational detail. However, it does not detail error responses or return formats.

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?

It is a single, direct sentence that avoids fluff and is highly effective at conveying the core function and constraint.

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 annotations (destructiveHint=true) and the specific constraints on input values, the description provides sufficient information for an agent to understand the action and its safe execution boundaries.

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 100%, so the schema itself is fully descriptive. The description provides a high-level explanation of what 'force' and 'torque' thresholds mean in this context, which slightly adds value beyond just the schema definition.

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 clearly states the tool's purpose: setting the robot's collision thresholds (force and torque). While it doesn't explicitly name the two parameters (force_n, torque_nm), it describes the resource being modified.

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 provides a key constraint on input values: 'Values above the policy maxima are rejected.' This clarifies operational limits for safe usage.

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?

Adds operational context the annotations do not cover: always available, never rate limited, never needs approval, and critically that it does not latch. Those are exactly the traits an agent needs before firing a safety-adjacent action; only the fate of an in-flight plan beyond the current trajectory is left implicit, and the output schema covers the response.

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 sentences, the action stated first, then availability guarantees, then the sibling routing. Every clause earns its place with no filler.

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 safety action with an output schema and full annotation coverage, the description supplies the remaining essentials: scope of the halt, non-latching semantics, and the escalation path to estop. Nothing an agent needs in order to call it correctly is missing.

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 and the baseline applies. It correctly implies no scoping argument is needed for such a call.

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 with scope: stop the current motion, covering both the arm trajectory and any gripper action. It is immediately distinguishable from the sibling estop, which blocks further motion rather than halting the current one.

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?

Explicitly names the alternative ('use estop to also block further motion') and the condition that selects it, plus the non-latching property that tells the agent this is a transient halt. An agent does not need to infer when to reach for estop instead.

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, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely new operational context: the policy allowlist gate and the possibility of human approval, both of which affect how an agent should plan the call. It stops short of explaining consequences (e.g. that deactivating a controller halts its control loop).

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 sentences, no filler, with the core action stated first and the constraint second. Everything present 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?

An output schema exists so return values need not be described, and the approval/allowlist behavior is disclosed. Minor gap: for a destructive, non-idempotent mutation it does not say whether switching interrupts active motion, which is the main thing an agent must anticipate.

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 100% and both parameter descriptions already state the allowlist constraint, so the description adds no syntax, ordering, or mutual-exclusivity detail beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 pair (activate/deactivate) and resource (ros2_control controllers), making it trivially distinguishable from read-only siblings like list_controllers or get_robot_state. No ambiguity about what the tool does.

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 description gives a hard precondition (allowlist membership) and warns a human may need to approve, which implies when the tool can be used. However it never states when to prefer this over alternatives or which situations require switching versus reconfiguration, so usage is only implied.

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