blender_measure

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about measuring real-world distances and the three measurement styles, but it does not disclose behavioral details like units, scene-scale assumptions, or how 'assembly' extent is computed.

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?

A single sentence front-loads the core purpose, immediately follows with the key use cases, and contains no filler. Every part of the sentence earns its place, and the mode enumeration makes the description compact yet informative.

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 measurement tool with no required parameters, six fully-described schema parameters, and a response_format parameter, the description plus schema gives an agent enough to invoke it correctly. It could have added what the returned measurement looks like, but given the annotations and complete schema coverage, this is a minor gap rather than a blocking omission.

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 all six parameters are individually documented in the schema. The description adds high-level semantic framing—bounding box, object centres, assembly extent—that aligns with the mode enum, but it does not provide additional parameter-level detail beyond what the schema already offers. Baseline 3 is therefore appropriate.

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—'Measure real-world distances'—and immediately enumerates the three supported measurements: bounding box, centre-to-centre distance, and assembly extent. This maps directly onto the 'mode' enum and makes the tool's purpose unmistakable even among many blender_* siblings.

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 phrase 'distances that are tedious to eyeball' gives a clear context: use this when precise measurements are needed rather than visual estimation. The three listed measurement cases also clarify when each mode is relevant, though it does not explicitly name alternatives or say when not to use this tool versus other blender_* measurement/analysis siblings.

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