measure_object

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

With no annotations, the description carries the full burden and does substantial work: it discloses the complete measurement set returned, the conditional cross-section behavior triggered by z >= 0, the fallback rule that thin-wall detection uses the nozzle line width unless min_wall is given, and that locations/heights are reported alongside findings. It does not state that the operation is non-destructive or anything about cost/runtime, which keeps it from a 5.

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?

It is a single long run-on sentence built from stacked clauses, so the reader must parse a wall of commas to extract the report contents. The core purpose is front-loaded, and every clause carries information, but better enumeration/line breaks would materially improve scanability.

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?

There is no output schema, so the description must describe return values, and it does so thoroughly — down to island length/width/thickest point and hole dimensions. Combined with the parameter semantics, an agent has enough to call this correctly; only the absence of any safety/side-effect statement leaves a small gap.

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 coverage is 0%, so the description must compensate, and it largely does: `part` is defined ('or its part `part`'), `z` is given meaning (cross-section height above bed, with the negative/default case implied), and `min_wall` is defined (wall thickness threshold in mm, defaulting to nozzle line width). Only `object` is left to inference, which is acceptable given its name.

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 an object ... in plate mm') and enumerates exactly what is reported: dimensions, position, per-part volume/surface, bed-contact area, joint clearances, thin walls. An agent can distinguish it from measure_between by the object-centric scope, though the sibling is never named.

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 only implied by the content ('if you want measurements of an object'). There is no explicit statement of when to prefer this over measure_between, no prerequisites, and no exclusion of cases. The only real conditional guidance is for `z` (cross-section only when z >= 0), which is parameter-level, not tool-level.

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