blender_cross_section_gallery

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which informs safety. The description adds significant behavioral context beyond that: the default axes/percent combinations, the X-axis heuristic, the object_names multi-object cut behavior, and the hard constraint that exactly one of object_name/object_names must be provided or a ValueError is raised. No contradictions with annotations.

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 organized into three compact paragraphs, each with a clear role: (1) what the tool does and why, (2) default parameters and heuristic guidance, (3) the object_names variant and input validation constraint. Every sentence carries useful information without repetition, though the formatting could be slightly tightened.

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 read-only rendering tool with strong annotations and no output schema, the description provides the essential context: purpose, use cases, default behavior, parameter semantics, and an error condition. It doesn't explicitly describe the return format (e.g., an image grid), but the name 'gallery' and the rendering context strongly imply it. Overall, it is complete enough for an agent to select and invoke correctly.

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 has 0% description coverage for all 4 parameters, so the description must compensate. It meaningfully explains the difference between object_name and object_names and the exclusivity constraint, and it provides defaults for axes and percents. However, it does not enumerate valid axis string values (e.g., 'x', 'y', 'z') or clarify the percent range, leaving custom-value construction somewhat ambiguous.

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 clearly states that the tool produces a 'Grid of cross-sections at multiple positions along one or more axes' and explicitly claims it is 'the only way to verify complex internal geometry' (knuckle interleave, pin holes, socket bores). This distinguishes it from sibling tools like blender_cross_section and scad_cross_section by emphasizing its gallery/multi-cross-section nature and its specific verification role.

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 gives concrete use cases: verifying complex internal geometry and chain joints/mating-part captivity. It also provides orientation guidance ('X-axis slices are usually most informative for hinges') and explains when to use the object_names variant. However, it does not explicitly state when NOT to use this tool in favor of the simpler blender_cross_section or other alternatives, so it stops short of a full when/when-not breakdown.

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