blender_sculpt

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

Annotations are all false, providing little safety information, so the description carries the burden of disclosing behavior. It adds useful context like 'dynotopo: enable/disable dynamic topology' and 'exit: leave sculpt mode (default back to OBJECT)', which hint at state changes. However, it does not disclose potential side effects of operations like 'mask_clear' or 'remesh_voxel', nor does it mention prerequisites (e.g., an active mesh object) or error conditions beyond a generic return format.

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 well-organized with a short intro, a bulleted operation list, a return format section, and a code example. Every element serves a purpose: the bullets cover all operations, the return format sets expectations, and the example clarifies invocation. It is concise without unnecessary fluff.

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 the tool's complexity (12 parameters, multi-operation dispatcher), the description is not fully complete. It provides a comprehensive operation list and an example, and the output schema covers return values. However, it omits critical details such as required parameters per operation, parameter ranges, and the meaning of ambiguous fields like prefer_session and adaptivity. This leaves the agent with reasonable but incomplete guidance.

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?

With 0% schema_description_coverage and 12 parameters, the description must compensate. It partially does by mapping operations to parameters (e.g., 'set_brush: assign brush with strength and radius' corresponds to strength and radius; 'remesh_voxel' implies voxel_size). The example shows usage of operation and object_name. However, many parameters like adaptivity, prefer_session, target_mode, and detail_resolution are not explained, leaving ambiguity for the agent.

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 'Sculpt mode operations for organic mesh editing' and enumerates a specific list of operations (enter, exit, set_brush, dynotopo, symmetrize, mask_clear, remesh_voxel, list_brushes) with short verb+resource explanations. It distinguishes itself from sibling tools by focusing exclusively on sculpt mode, which is a unique domain in the toolset.

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 establishes clear usage context by stating the tool is for 'Sculpt mode operations' and providing operation-specific details such as 'enter: switch object to sculpt mode' and 'exit: leave sculpt mode (default back to OBJECT)'. It implicitly tells the agent when to use this tool (when sculpt-related actions are needed) versus alternatives, but it does not explicitly name alternative tools or state 'when not to use' conditions.

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