export_web_optimized

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

No annotations are supplied, so the description carries the full burden. It does useful work by disclosing the return shape and the default quality/compression values, but it never says whether both files are always written regardless of which is smaller, whether existing files in output_dir are overwritten, or whether scaling affects the source document or only the exported copies. For a write-to-disk tool with zero annotation coverage, those gaps matter.

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 purpose sentence is front-loaded, then a compact parameter block, then the return shape. Nothing is wasted and the bulleted format is easy to scan. The parameter block largely mirrors the schema's property names, but with 0% coverage that restatement is earned rather than redundant.

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 no output schema, the explicit 'Returns: {jpeg_path, jpeg_size, png_path, png_size, recommendation}' line is valuable and completes the picture for a caller. All six parameters are covered. Remaining gaps are behavioral rather than structural: overwrite policy and whether max_width/max_height mutate the live image.

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 0%, so the description is the only source of parameter meaning, and it documents all six: output_dir, jpeg_quality (1-100, default 85), png_compression (0-9, default 9), max_width/max_height as optional pre-export scaling, and image_index (default 0). The only weak spot is image_index, which does not explain what the index refers to or how to obtain valid values.

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?

States a specific verb and resource (export an image) plus the distinguishing behavior: produces both JPEG and PNG so the caller can pick the smaller. That differentiates it from export_image, batch_export, and export_icon_sizes without naming them. The phrase 'choosing the smaller format' slightly overstates the tool, since the Returns list shows both files plus a recommendation rather than a single chosen file.

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 'web optimized' framing implies when to reach for this over export_image, but there is no explicit statement of when to use it versus export_image or batch_export, and no prerequisites or exclusions. Usage has to be inferred from the tool's name and the dual-format behavior.

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