armorpaint_set_object

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

The annotations already declare readOnlyHint=false and idempotentHint=false, establishing that this is a non-idempotent mutation. The description confirms the concrete operations (renaname, visibility) but adds no deeper context such as side effects, reversibility, or what happens when name/visible are null. With annotations carrying the base safety profile, the description adds modest value beyond them.

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 eight-word sentence with high information density and front-loaded verbs. Every word earns its place with no fluff. It is slightly terse — it could have added one clause of usage context without padding — but it remains appropriately sized for a simple setter.

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?

Complexity is low (three primitive params, no nesting, one required), and an output schema plus annotations are present, so retur n values need no explanation. Yet the description still omits meaningful context: how index identifies a mesh, whether name and visible are independent or combined, and when to choose this over select_object. Adequate for a simple mutator, but with clear gaps.

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 must compensate. 'Rename' maps to the name property and 'show/hide' maps to visible, providing a useful operation-to-parameter linkage. However, the required index parameter is left entirely unexplained, and the nullable optional semantics of name/visible are not addressed. This is only partial compensation for the coverage gap.

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 specific verbs and a resource: 'Rename or show/hide a mesh object.' It is clearly distinct from siblings such as armorpaint_select_object (selection) and armorpaint_import_mesh (importing). It falls short of a 5 because the dual-operation phrase is slightly ambiguous about whether name and visible can be combined, and it does not explicitly name the sibling it is not.

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 guidance is given on when to use this tool versus alternatives. It does not mention that index refers to an already-listed/imported mesh, nor does it distinguish itself from armorpaint_select_object or the other setter sibs such as set_layer/set_camera. An agent must infer selection criteria solely from the sibling name list.

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