set_human_target

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a MoveTo task is issued, but says nothing about whether the task executes immediately, how preview affects behavior, what happens to prior tasks, or any side effects. This is a significant transparency gap for a motion command 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 a single, front-loaded sentence with no wasted words. It clearly communicates the core action and the 'exactly one target' constraint. However, it is arguably too sparse for a tool with eight parameters, so it is concise but not optimally informative.

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 eight parameters, no annotations, and 0% schema description coverage, a one-sentence description is not enough for an agent to invoke the tool correctly. The output schema exists, so return-value detail is not required, but the description still fails to explain how to specify a target or what happens when preview is enabled or disabled.

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%, and the description does not compensate. It gives no explanation of target_position vs target_prim_path, speed_mps, auto_brake, preview, command_id, or idempotency_key. An agent must infer all parameter semantics from names alone, which is insufficient.

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 ('Issue') and a specific resource ('Behavior Agent MoveTo task'), and adds a clear scope constraint ('exactly one target'). It is clear enough to be distinguished from sibling human-control tools like set_human_look_at or set_human_idle, though it does not explicitly name an alternative.

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 'MoveTo task' phrasing implies this tool is for commanding a human agent to move to a target, as opposed to idle or look-at behaviors. However, it does not state when to prefer this over set_human_behavior or other sibling tools, and there are no explicit exclusions or alternative references.

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