show_avatar
Toggle avatar visibility in CLO3D to show or hide the 3D human model during project inspection or presentation.
Instructions
Show or hide the avatar.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| show | No |
Toggle avatar visibility in CLO3D to show or hide the 3D human model during project inspection or presentation.
Show or hide the avatar.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It accurately states the visibility-toggle behavior, which is helpful, but it does not disclose any context such as whether the change is persistent, whether it applies to the currently selected avatar, or whether it only affects the 3D viewport. This is adequate for a simple toggle, not rich.
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 short sentence with no filler or redundancy. For a tool with one boolean parameter, this level of conciseness is appropriate and front-loads the function clearly.
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 is simple and has no output schema, so not much is required. However, the description leaves open which avatar is affected, what 'show or hide' means in the broader scene context, and whether state persists. It is minimally viable but not fully complete.
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 clarify the only parameter. 'Show or hide' implies the boolean sets visibility state, but it does not explicitly map true to show and false to hide. The meaning is recoverable but largely inferred.
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 pair ('show or hide') and a clear resource ('the avatar'), so the agent understands the tool's core function. It does not explicitly differentiate from related siblings like get_avatars or import_avatar, so it stops short of a 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?
No guidance is given about when to use this tool versus alternatives such as get_avatars or import_avatar, nor when the boolean should be true versus false. The agent has to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.