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

Adds substantial context beyond the annotations: billing applies to completed jobs even with zero images extracted, JPEGs returned byte-for-byte including EXIF/GPS, resources may contain unused/hidden images, 60 s timeout, and a prompt-injection caveat about returned text. Annotations (readOnlyHint=false, idempotentHint=true) are not contradicted, and the description fills in costs and failure modes they cannot express.

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?

Front-loaded with the core action and return shape, then limits, then caveats. Dense but nearly every clause carries operational weight; the format/limit sentences are telegraphic and could be marginally tighter, but nothing is padding.

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?

An output schema covers the return shape, freeing the description to spend its budget on limits, supported formats, pricing, timeout and security posture — exactly the gaps structured fields cannot fill. An agent can decide feasibility and cost from this text alone.

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 100%, so the schema already documents url, pages, output and pdf_base64 with limits. The description reinforces the output=url time-to-live and adds aggregate limits (500 input pages, 100 selected), but adds no new syntax or semantics for the individual parameters. Baseline 3 applies.

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?

Specific verb + resource ("Extract embedded raster images from a PDF") followed by an explicit negative scope ("no inline images, attachments, vectors, rendering or captions"), which distinguishes it from siblings like pdf_to_images and pdf_rasterize that render pages. An agent knows immediately that this pulls existing XObjects rather than rasterizing.

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?

Clear usage context: when to pick output=url vs inline base64, the fact that unsupported formats are enumerated in the manifest rather than failing, and that encrypted input is refused. It stops short of naming a sibling tool by name (e.g., 'for page rendering use pdf_to_images'), so routing is inferred rather than stated.

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