set_origin

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It clearly states that geometry is not moved, which is a key non-destructive behavior. However, it doesn't disclose any side effects, such as whether the operation is undoable, how it interacts with parenting or modifiers, or whether it affects the object's local axes. The description is better than a tautology but lacks depth on what happens to the object's transforms.

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 sentence that communicates the core purpose clearly and efficiently. It front-loads the action and the resource, and immediately clarifies that geometry is unaffected. There is no wasted wording. It could have been improved by adding a couple of usage hints, but as is, it is appropriately concise.

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 2 parameters, no output schema, and no annotations, the description is thin. It explains what it does but not why an agent would call it over alternatives like set_transform or when to choose specific modes. The mode parameter description provides some context, but the overall description leaves gaps: it doesn't mention that the name is the object to modify, nor does it give examples of when each mode is appropriate (beyond BASE). For a tool that modifies objects, more guidance is needed 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 description coverage is 50% (only the mode parameter has an extended description; name has no description beyond its title). The description itself doesn't elaborate on parameters—it doesn't explain how to use the mode or what name refers to. However, the mode parameter's description in the schema does add context (e.g., BASE puts origin at footprint), which helps compensate. But for names, the agent gets almost no guidance beyond 'Name', so the description adds limited value beyond the 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?

The description uses a specific verb ('Move') and resource ('object's origin'), clearly distinguishing this from sibling tools like set_transform which deal with object transforms. It also clarifies that geometry is not affected, which adds precision. However, it doesn't mention the `mode` parameter or the alternatives, which slightly limits purpose clarity for agents unfamiliar with Blender origin semantics.

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 implies usage when an object's origin needs to be repositioned without moving its geometry, and the mode parameter description clarifies one specific use case (BASE for props standing on ground). However, it doesn't explicitly state when not to use this tool (e.g., if you want to move geometry, use set_transform) or when to use a particular mode over another. No explicit alternatives are pointed out.

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