wave_design_measure

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

With no annotations, the description carries the transparency burden and does a good job: it discloses the external package/command, conditional geometry masking, plate rasterization, optional cropping, and the return payload. It does not explicitly confirm a read-only/no-side-effect profile, but the wording 'measure' and 'Returns the measurement JSON' strongly imply a non-mutating analysis tool.

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?

One dense sentence conveys the core command, input options, preprocessing behavior, and output. There is no filler or redundancy; the content is front-loaded and every phrase contributes.

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?

The description plus schema covers all parameters and, because there is no output schema, it helpfully lists the returned JSON categories. It could be slightly more complete by explicitly stating that at least one of image/plate must be supplied and what happens if both are given, but the overall picture is sufficient for normal invocation.

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 100%, so the schema already fully documents all four parameters. The description adds a high-level view of how the parameters combine (image/plate alternative, geometry masking, crop region) but does not add new syntax or formats beyond the schema.

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 states a specific action ('Run @wave-av/loc-study's measure') and the target resource (image or plate SVG), and it names the result ('measurement JSON (bokashi/keyblock/palette/composition)'). It is clear and not tautological, but it does not explicitly contrast itself with sibling tools such as wave_design_extract or wave_design_contract.

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 implies when to use the tool: whenever a measurement JSON from an image or plate is needed, with options for cropping and geometry masking. It does not provide explicit when-not-to-use guidance or distinguish this tool from wave_design_extract or wave_design_contract, so usage is left mostly to inference.

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