diff_images

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

The annotations only indicate readOnly=false, destructive=false, and idempotent=false. The description adds substantial behavioral detail beyond those annotations: sidecars are written beside source prefixes, the wrapper refuses to run if any potential sidecar exists, and --overwrite is never enabled. This is exactly the kind of safety-relevant behavior an agent needs to know.

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 compact and front-loaded, with every sentence earning its place. It clearly separates the primary purpose from important behavioral caveats. It is not overly verbose, though it could be slightly better structured by explicitly labeling the parameters or constraints.

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 10-parameter tool with no schema-level parameter descriptions, this description is incomplete. It gives good safety context but fails to define the required prefixes or the key output/tuning parameters. Even with an output schema present, the agent lacks enough information to confidently construct a correct 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?

The input schema has 10 parameters and 0% description coverage, so the description had to compensate. It only vaguely references 'source prefixes' and never explains reference_prefix, source_prefix, fuzz, alpha, output, timeout, verbose, show_all, max_bytes, or extra_args. This leaves the agent to guess the meaning of most arguments.

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 ('Compare image sets') and a concrete deliverable ('HTML report plus new diff/thumbnail sidecars'). It is clearly differentiated from trace-oriented siblings like diff_traces and diff_state, and from dump_images, by its focus on image comparison and sidecar generation.

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 intended use case is implied clearly: comparing image sets and producing diff/thumbnail sidecars. It also gives an important precondition (refuses to run if potential sidecars exist). However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, so usage guidance remains mostly implied.

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