Render a 360-degree turntable animation of the active Rhino model to a PNG sequence or GIF, enabling clear rotating product views.
Render a turntable animation to output_path (PNG sequence or GIF).
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, indicating this is a mutating/state-changing operation, likely creating files. The description discloses output is a PNG sequence or GIF, but does not state that it generates a file on disk, whether it requires an active document or view, whether it spins the camera/object, or any other side effects. With no readOnlyHint=true, the agent needs more behavioral detail but gets only a terse instruction.
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?
Single sentence, no fluff, communicates core function and output format. Could be improved by naming alternatives or adding context but it is efficient and readable.
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?
Tool generates an animation, requires output_path, has width/height/frames, and has an output schema. Missing context: how frames relate to rotation angle, whether it exports PNG sequence or GIF based on file extension, whether it renders current view or spins model, and relationship with rhino_turntable_render. Agent may call it correctly from schema but will lack key behavioral semantics.
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% and no parameters have descriptions except doc_id. However, the description mentions output_path as destination and parameters are semantically clear from names: frames, width, height, doc_id. It adds no extra meaning beyond the schema, so 3 is baseline given low coverage is compensated by self-explanatory names.
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?
Description states 'Render a turntable animation to output_path (PNG sequence or GIF)', which clearly identifies the verb, resource, and output format. It distinguishes from siblings like rhino_render_preview, rhino_render_viewport, and rhino_turntable_render by focusing on animation, though it doesn't explicitly name those alternatives or explain difference.
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 explicit guidance on when to use this tool vs alternatives. Sibling tools like rhino_turntable_render and rhino_render_viewport overlap conceptually, but the description does not clarify which one to pick for a turntable animation task. Context is implied by the word 'turntable' but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.