image_to_pdf

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

No annotations are provided, so the description carries the burden. It discloses that EXIF rotation is applied and that page size can be auto or fitted to A4/Letter. However, it doesn't mention whether the operation is destructive (e.g., whether it overwrites existing files), whether it requires authentication, or what happens with unsupported image formats. The $0.01 pricing hint is useful but not behavioral. A 3 is appropriate because the description adds some behavioral context but leaves gaps.

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 a single, dense sentence that front-loads the core function and then lists key options. Every phrase earns its place: 'Combine one or more images', 'local paths', 'JPEG/PNG/WebP/…', 'auto page size or fitted to A4/Letter', 'EXIF rotation applied', and the price. No wasted words.

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 tool with 5 parameters and no output schema, the description covers the main use case but omits important details: what the output looks like (return value), whether output_path is required or optional, and how margin and idempotency_key behave. The sibling context (pdf_merge, pdf_to_images) helps, but an agent would still need to inspect the schema for margin, output_path, and idempotency_key semantics. A 3 reflects the partial coverage.

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 must compensate. It mentions 'one or more images' (files), 'auto page size or fitted to A4/Letter' (page_size), and 'local paths' (files). However, it doesn't explain margin, output_path, or idempotency_key. The description adds some meaning for files and page_size but leaves the other three parameters undocumented. Baseline 3 is fair given partial compensation.

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 clearly states the tool's function: combining one or more images into a single PDF. It specifies the input types (local paths, JPEG/PNG/WebP/…) and key options (auto page size or fitted to A4/Letter, EXIF rotation applied). This distinguishes it from sibling tools like pdf_merge (which merges existing PDFs) and pdf_to_images (which converts PDFs to images).

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 this tool: when you have image files and need a PDF output. It doesn't explicitly state when not to use it or name alternatives, but the context of sibling tools (pdf_merge, pdf_to_images) makes the use case clear. The mention of 'local paths' gives a hint about input requirements, though it could be more explicit about not accepting URLs or remote files.

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