render_page

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description does add one behavioral fact beyond the annotations: that the return is a visual image rather than extracted text, which matters since there is no output schema. It says nothing about image format, whether dpi affects output size, or that encrypted PDFs may need a password.

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?

A single short sentence with no filler; the purpose leads and the use cases follow. It is efficient, though the brevity borders on under-specification given four undocumented parameters.

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 four parameters at 0% schema coverage, no output schema, and no parameter documentation, the description leaves the agent guessing about path format, dpi semantics, password handling, and the exact nature of the returned image. The readOnly annotation covers safety but not the operational gaps.

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 0% for four parameters, so the description must carry parameter meaning and largely fails. 'one page' loosely maps to the page parameter, but path, dpi (including its effect on image quality) and especially password for protected files are entirely unexplained.

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 phrase 'A picture of one page' communicates the resource (a single page) and the output form (an image), but there is no explicit verb such as 'render' or 'convert', so the agent must infer that this produces a rasterized page image rather than a description. It is distinguishable from read_text and ocr by implication, but the differentiation is never stated.

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?

'to look at layout, stamps, signatures or scans' gives an implied use case for visual inspection, which is more than nothing. However, no alternatives are named (e.g. use ocr or read_text when you need text rather than visuals), and there is no when-not-to-use guidance.

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