Scan local document images

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description adds genuinely new context such as the 3–6 pixel edge inset caused by source warping and that output pixels/PDF payloads and page layout are verified. The local-browser requirement is a real operational constraint not expressed in structured fields. It doesn't say whether an existing output file at output_path is overwritten, which is a notable omission for a writer 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?

Roughly four tight sentences, front-loaded with the core action and followed by constraints and the non-goals. The telegraphic style ('Perspective-correct explicit document corners...') is dense but every clause carries information; no filler.

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?

With 11 parameters, 18% schema coverage, no output schema, and a required JSON config whose structure is never described, the definition leaves too much undocumented for an agent to invoke it confidently. It should at minimum sketch the config file's contents and explain the tuning knobs (strength, quality, dpi, max_side).

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 only 18% (just the three path params), yet the description does not explain dpi, quality, max_side, strength, margin_mm, page_size or format. The one useful addition is that config_path supplies 'explicit document corners', hinting at the JSON payload's purpose, but the format of that JSON and the meaning of strength/quality remain unspecified in both places.

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 names a specific verb and pipeline: perspective-correct explicit document corners from a local JSON file, then clean up pages into a PDF or PNG. It also distinguishes itself from neighbors by ruling out OCR / corner detection and from generic converters by requiring a browser renderer. An agent can tell this apart from siblings like abox_image_convert or abox_receipt_extract.

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?

It gives clear exclusions ('Does not detect corners or perform OCR') and an environmental prerequisite ('Requires a local browser'), which effectively tells the agent when this tool is the wrong choice. It stops short of naming explicit alternatives (e.g. use abox_receipt_extract for OCR), so it lands at 4 rather than 5.

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