generate_product_base

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

No annotations are provided, so the description carries full behavioral burden. It does disclose real traits: the tool opens Kiln's interactive inline 3D stage, oversized meshes are auto-decimated for the stage, the PNG preview is a floor not the full result, and it requires Kiln Pro. That is meaningful beyond a bare verb. It still omits side effects (does it persist a design?), auth/prerequisite details beyond Pro, and failure behavior, leaving gaps for a mutating/generating 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 text is bloated with pricing URLs, an upgrade pitch, and a verbose prose explanation of the inline stage repeated across two sections. The useful sentence about Pro requirement and stage behavior is buried among upselling that does not help tool selection, and the uppercase 'MAKE DOORS' block adds noise rather than front-loaded signal.

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?

There is no output schema, so the description must explain returns; it covers the interactive stage and PNG preview, which helps. But it leaves open what the generated 'base' actually is, how brief_id/template selection works, and what the caller should expect to do next. Given 6 parameters and a generation workflow, it is only partially 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 83% across 6 parameters, so the schema largely carries the burden and baseline 3 applies. The description adds nothing about product_type, size_mm, size_preset, thickness_mm, brief_id, or include_step, so it neither compensates nor confuses. It is adequate by virtue of the schema, not the text.

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 opening sentence states a specific verb and resource: 'Generate a 3D-printable product base shape from a template (Pro).' That is clear enough to place the tool among generation siblings. However, the clarity is diluted by a long marketing/upsell block and a tangential 'MAKE DOORS' aside about design_session and compile_scad that does not describe this tool's own purpose.

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 never states when to use generate_product_base versus clear alternatives such as generate_from_template, smart_generate_from_template, generate_template_variations, or generate_decorated_product. The 'MAKE DOORS' note routes the agent between design_session and compile_scad, which is ecosystem advice, not a use-condition for this tool, and it reads as confusing rather than guiding.

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