wizard_product_shot

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that render is CPU-heavy, that output_path can be empty for a temp file, and that the tool sets up a complete scene. But it does not explain side effects on the existing scene (e.g., whether it creates a new scene, replaces objects, or leaves materials/models behind), nor what the return value is. Some useful context, but not comprehensive.

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 front-loaded with the purpose, then lists components, then provides an Args section with each parameter on its own line. It is slightly longer than strictly necessary, but every sentence earns its place; no filler or repetition.

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?

Given there is no output schema and no annotations, the description should cover return values and side effects. It covers the rendering and output_path behavior but is silent on what the tool returns and what happens to existing scene contents. For a complex wizard tool, this is a material gap, though the rest of the context is well specified.

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%, yet the description compensates fully: it lists every parameter with added meaning—allowed product_type values, [R,G,B] color ranges and defaults, render CPU-heavy guidance, sample suggestions (16-32 for preview), and output_path behavior. This exceeds what the bare schema provides and gives the agent actionable parameter semantics.

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 opens with a specific verb and resource: 'Create a complete product photography scene in one call.' It enumerates what gets set up (product object, backdrop, 3-point lighting, camera, materials, render settings) and explicitly promises a preview, so any agent can tell this is a high-level one-shot scene builder, distinct from lower-level siblings like setup_studio_3point or configure_render.

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?

It clearly states the intended use case ('product photography scene in one call', 'One tool call = finished shot'), and it adds conditional guidance for the render parameter ('Keep False for scene building'). However, it does not name alternative tools or explicitly state when not to use this wizard, so it stops short of full exclusion guidance.

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