rhino_set_osnap

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

With no annotations, the description carries the full burden. It does disclose key behavior: it enables specific snap modes, disables all on empty list, and defaults to a standard set. However, it does not clarify whether the current snap modes are replaced or augmented, or whether object snapping must be globally enabled for this to take effect.

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 organized with Args/Returns sections, and the main purpose is front-loaded. The mention of 'controller: RhinoController instance' is unnecessary given the schema, and the docstring formatting is a bit verbose, but overall the size is appropriate for the tool.

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?

The tool has no annotations, minimal schema detail, and 0% schema description coverage, so the description must be nearly self-sufficient. It covers modes and defaults well, but the schema type mismatch for 'modes' and the undocumented 'controller' parameter leave an agent unable to reliably construct a valid call. It also does not clarify the relationship with the sibling 'rhino_set_snap'.

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 fully explain the parameters. It gives examples and defaults for 'modes', but the schema declares 'modes' as a string while the description calls it a list. It also mentions a 'controller' parameter that is absent from the schema, creating ambiguity about how the tool should actually be invoked.

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 opens with a specific verb and resource: 'Set active object snap modes.' This clearly identifies the tool's function. However, it does not differentiate it from the sibling tool 'rhino_set_snap', which appears to have overlapping purpose, so it cannot receive 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?

The description provides concrete usage guidance: example mode names, the effect of an empty list ('disable all'), and the default mode set. This is clear practical context. It does not mention when to prefer this over alternatives like rhino_set_snap, so it stops short of a 5.

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