transform_object

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully specifies that position is 'world position,' rotation is 'in degrees,' and scale is 'new scale factors,' providing some conventions. However, it does not disclose whether omitted transform fields are left unchanged or reset, nor does it mention error behavior or side effects for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and efficiently structured: a one-sentence summary followed by a terse Args list. Every line adds distinct information, and the key operation 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?

Given the tool has no annotations, 0% schema coverage, and manages a 3D transform, the description covers essential parameters but leaves important operational details unstated. It does not explain partial-update behavior when position, rotation, or scale is null, nor does it mention units for position/scale. The presence of an output schema reduces the need to document return values, but behavioral gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for the schema's silence. It clearly explains prim_path, position, rotation, and scale with formats, which covers the main functional parameters. The optional command_id and idempotency_key parameters are undocumented, but they are common cross-cutting parameters and the primary parameters are well described.

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 specific action, 'Set the transform (position, rotation, scale) of an existing object,' with a clear verb and resource. It also enumerates the three transform components, making the tool's scope immediately understandable and distinct from siblings like create_object or get_prim_info.

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 'existing object' implicitly tells the agent this tool is for modifying an already-created object, not for creating or deleting one. However, it does not explicitly name alternatives or state when not to use this tool, leaving the routing to inference.

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