read_page_image

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

Annotations already mark the tool read-only, idempotent, and non-destructive, so the description only needs to add operational context. It adds the Poppler prerequisite and notes that page numbering is 1-based, which is useful, but it does not describe the return format or failure behavior. This matches the lower bar for annotation-backed tools.

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 three short sentences with no filler. The core purpose is front-loaded, and the indexing detail and prerequisite are separated cleanly.

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 simple read-only tool the description is mostly sufficient, and the Poppler prerequisite is helpful. However, with no output schema and an unexplained 'id' parameter, the agent is left to infer where the id comes from and what form the returned image takes.

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 for undocumented parameters. It clarifies that 'page' is 1-based, but the required 'id' parameter is never explained, leaving ambiguity about what identifier should be passed and where it comes from.

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 names a specific action ('Inspect an original PDF page as an image') and a clear resource, with concrete use cases like plots, tables, equations, and scanned pages. It is clear about what the tool does, but it does not explicitly differentiate from siblings such as fetch or search, so it stops short of a 5.

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 phrase 'especially for plots, tables, equations or scanned pages' gives a clear context for when this tool is appropriate, implying it is for visual content where text-based extraction may fail. It does not state exclusions or explicitly name alternatives, but the guidance is otherwise clear.

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