preview_decorated_mesh

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

With no annotations, the description carries the full burden. It does valuable work disclosing that the tool opens an interactive viewer panel/link in the host and that oversized meshes are decimated automatically (a non-obvious transformation of the input). But it says nothing about what happens on Pro-license failure, whether files are written to disk, or how the PNG preview is returned.

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 inline-3D-stage behavior is described twice (once in the opening sentence, again in an all-caps paragraph) and the middle block is pure upsell — 'Everything in Free, plus calibration that learns your printer... Upgrade: <URL>'. Roughly half the text is promotional rather than operationally useful, and the duplicated paragraph pushes the useful detail to the end.

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?

Ten optional parameters, no annotations, no output schema — the description should therefore clarify input requirements and return shape, and it does neither. It never explains what source_gcode_path or output_dir must contain to produce a preview, nor what a successful call returns (a path? an image? just the stage), which is the central ambiguity for a preview tool.

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 100%, so the baseline is 3, but the schema entries are bare 'Default: X' stubs with no semantic meaning. The description adds nothing for any of the 10 parameters, so opaque ones like source_gcode_path, engine_output_dir, decoration, and image_scale remain unexplained by either source.

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 first sentence states a specific verb and resource: 'Render a 3D preview of a mid-print decorated part.' That distinguishes it from generic renderers in the sibling list such as render_model_preview and visualize_model, though it never names those siblings explicitly to sharpen the boundary. The purpose is unmistakable, but the '(Pro)' tag and marketing copy dilute the opening.

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 phrase 'mid-print decorated part' implies the usage context, and 'Requires Kiln Pro' is a real precondition an agent needs. However, there is no explicit when-to-use/when-not guidance and no mention of how this differs from preview_texture_2d, render_model_preview, or decorate_during_print, all of which an agent could plausibly pick instead.

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