pdf_render_page

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

Beyond the annotations, the description discloses the dpi ceiling and default, the three accepted source forms, the writable-server prerequisite for save_as, and the PDFium runtime dependency — all real operational context. It also implicitly surfaces a tension with readOnlyHint=true by admitting an optional file write, but it does so honestly and gates it behind save_as, so the agent is not misled.

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?

Three sentences, front-loaded with the action and return type, then inputs, then the optional side effect and dependency. Dense and largely waste-free, though the parenthetical dpi and source phrasing compresses several distinct facts into one sentence.

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 correctly states that an image is returned, and it covers sources, resolution, and the optional save path. Only edge behavior — out-of-range page numbers, fetch failures on url/data, overwrite semantics beyond the schema default — goes unmentioned, which is minor for a 7-param tool with full schema 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 coverage is 100%, so every parameter is already documented with defaults and limits; the description mostly restates the dpi range and the path/data/url choice. It adds a little meaning by framing save_as as an optional extra that requires a writable server, but no more than that.

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 first clause gives a specific verb and resource ('Render one PDF page to a PNG image') plus the output format, so the tool is unambiguous. It implicitly separates itself from pdf_text by offering 'read a scanned page' as the motivating case, but it never names the sibling tools to make the distinction explicit.

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?

'e.g. to read a scanned page' gives one concrete scenario that hints at when to prefer this over pdf_text, which is useful. There is no explicit statement of when not to use it, no named alternative, and no guidance on choosing among the three mutually exclusive PDF sources beyond the schema's own note.

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