blender_measure

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

With no annotations present, the description carries the full behavioral burden. It adds one genuinely useful trait — results are in world units — which clarifies the output without referencing Blender's unit system. However, it does not state that measurement is read-only/non-destructive, what the return value looks like, or how the tool behaves when mode-specific parameters (e.g., point_a/point_b for DISTANCE) are missing. The verb 'measure' implies non-destructiveness, but this is never made explicit.

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 entire description is a single 15-word sentence that front-loads the action ('Measure') and enumerates every supported measurement type. There is no filler, no repetition of the tool name, and each clause adds information. The 'in world units' qualifier earns its place as the only non-obvious detail an agent would not infer from the schema.

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?

This is a multi-mode tool with six parameters, no annotations, and no output schema, so the description carries a heavy burden it only partially meets. It does not state what the tool returns (a scalar value, a vector for BBOX, or a dict of measurements), which is critical since there is no output schema and an agent needs the result shape for downstream steps. It also does not clarify that object_name is required even in DISTANCE mode or how invalid combinations (e.g., EDGE_LENGTH without edge_indices) are handled. The description conveys what the tool measures but not enough about how to invoke it correctly and interpret results.

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 100%, so the baseline applies: the schema already documents every parameter, including mode-to-parameter mappings (point_a/point_b for DISTANCE, edge_indices for EDGE_LENGTH, two vertex_indices for VERTEX_DISTANCE). The description adds modest value by listing the mode names in prose and establishing that coordinates and results are in world units, which informs how to interpret point_a/point_b. It does not resolve remaining ambiguities like how many edge indices are required in EDGE_LENGTH mode, but the schema carries most of the load.

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 the verb 'Measure' and names four concrete measurement types (distances, bounding box dimensions, edge lengths, vertex-to-vertex distances), making the tool's scope immediately recognizable. These enumerated types implicitly differentiate it from measurement siblings like blender_measure_surface_area, blender_measure_volume, and blender_measure_edge_angle, which cover different quantities. The 'in world units' qualifier further pins down the semantics.

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?

Usage is implied through the enumerated measurement modes: an agent can infer this tool handles linear measurements while area, volume, and clearance have dedicated siblings. However, the description never explicitly states when to prefer this tool over blender_measure_surface_area, blender_measure_volume, blender_measure_clearance, or blender_measure_edge_angle, nor does it name them as alternatives. There is no conditional guidance about when each of the four modes should be chosen.

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