check_image_resolution

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

With no annotations available, the description carries the full behavioral disclosure burden and does so well: it details the parsing approach for PNG/JPEG/GIF, the comparison logic, the min_dpi flagging behavior, format-specific outputs for EMF/WMF and other formats, and explicitly states 'Read-only'. There is no hidden mutation or undefined format handling.

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 dense but carefully structured: a one-line summary is followed by the calculation method, format-specific behavior, domain context, and a read-only safety note. Every sentence contributes operational or decision-relevant information with 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?

The description covers the calculation method, threshold semantics, format edge cases, domain benchmark, and read-only nature; the existing output schema accounts for the return shape. The only minor gap is that it never explicitly states that file_path is the path to the document whose embedded images are being inspected.

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 description explains min_dpi as the threshold below which images get flagged and relates it to the 300 DPI publishing standard, adding value beyond the bare integer schema. file_path is not explicitly described as the path to the containing document, but the tool's purpose and reference to 'part bytes' make that role inferable.

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 precise statement of what the tool computes: effective print resolution (horizontal and vertical DPI) for every image in the document, based on native pixel size versus displayed size. This clearly differentiates it from siblings like list_images, resize_image, replace_image, and extract_images, none of which assess print resolution.

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 gives clear context for when the tool is relevant by mentioning that publishers typically require 300 DPI for print figures, and it explains how different image formats are classified. It does not name an alternative tool to use instead in specific situations, but no sibling has overlapping resolution-checking functionality.

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