Save front, back, left, and right views of the 3D garment window as PNG files. Specify a base file path to generate four angle images.
Save front, back, left and right images of the 3D window as PNG files.
To look at the garment yourself, use capture_3d instead (returns the images).
Args: file_path: Base path; files are saved as _front.png, _back.png, ...
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
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 burden of disclosing side effects. It clearly states that files are written to disk and describes the exact naming convention (<base>_front.png, etc.). It does not mention overwrite behavior or return/success indicators, but the primary behavioral contract is transparent enough for a simple export tool.
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 front-loaded. The first sentence states purpose, the second routes to the relevant sibling, and the Args block is short. No sentence is wasted.
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?
For a single-parameter, low-complexity tool without an output schema, the description is nearly complete: it covers behavior, naming, and the sibling alternative. It stops short of stating what the tool returns on success/failure, which would make it fully self-contained, but the core usage context is sufficient.
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?
The schema only says file_path is a string, but the description adds essential meaning: it is a base path, not a literal final file path, and it defines how output filenames are derived. This fully compensates for the 0% schema description coverage.
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 a specific verb ('Save'), a concrete resource ('front, back, left and right images of the 3D window'), and the output format ('PNG files'). It also explicitly contrasts with capture_3d, which returns images instead, making the tool's role clear among siblings.
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 gives explicit usage guidance by naming capture_3d as the alternative when the agent needs to view images directly. It does not compare against other export siblings such as export_thumbnail or export_turntable, but the core decision between saving and returning images is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.