Get PDF Page Image

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds meaningful behavior the annotations cannot: payload-size rejection above ~1MB, out-of-range page rejection, 1-based numbering, and that only the requested PNG is included. These are real operational constraints an agent must plan around.

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-loads the core purpose before diving into parameter and return detail, and each sentence carries distinct information with no filler. It is dense but every clause earns its place; only the long parenthetical clauses make it slightly heavy.

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 description usefully enumerates the return fields (target_type, target_id, page_number, page_count, filename/path/size/mime, page_image_b64), and constraints are covered. The gap is the unexplained target_type/target_id semantics for a tool that requires both.

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 carries the param burden, yet it only documents two of four: page_number (1-based) and max_dimension_px (default 1024, longest side, larger grows the payload). target_type and target_id semantics, including the three enum values, are left entirely undocumented.

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 ('Return one rendered PDF page') and immediately distinguishes itself from the sibling get_rendered_pdf by noting it does not change that tool's pre-rendered preview PNGs. An agent can tell what this produces without opening the schema.

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 'explicit opt-in visual payload' framing tells the agent this is the deliberate choice for pulling a single page image, and the closing sentence contrasts it with get_rendered_pdf's default previews. It establishes context and the alternative, but never states an explicit trigger condition such as 'use this when you need a page the pre-render doesn't cover.'

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