Skip to main content
Glama

get_page_image

Render a datasheet element, caption, region, or full page as a PNG image so an agent can read printed values; choose elements or regions at 300–600 dpi to limit input cost.

Instructions

The original as a PNG image: an element, a caption, a region or a full page. Read the values from this image. An element, a caption or a region is rendered at 300 to 600 dpi: prefer them, because a full page costs more input. A full page is correct for a table that fills the page. It is rendered at the resolution that fits max_px. Gives a line with the page, the region, the dpi and the size, and the image.

Input Schema

NameRequiredDescriptionDefault
bboxNoOr a region [x0, y0, x1, y1] in pt, origin at the top left of the page (the units of get_page_map). Needs page.
pageNoThe page number, from 1. Not necessary with element.
max_pxNoThe maximum long edge of a full-page image in pixels (256 to 8000). 1600 is enough for a table that fills the page. Use more for small print or a fine drawing.
captionNoOr a caption label, for example "Table 57" or "Figure 3-1": the image shows this table or figure. A table that continues on the next pages gives one image for each page.
elementNoAn element ID from get_page_map or list_items, for example p7.T1: the image shows this element.
documentYesThe document: its reference from list_documents, project_status or add_document (the first 12 characters of its SHA-256). A longer SHA-256 prefix or the numeric document ID also works.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden and does well: it states the image format, DPI range for element/caption/region, full-page resolution behavior tied to max_px, relative input cost, and the returned line with page, region, dpi, size, and image. It lacks permission or failure-mode details, but those are less critical for a read-only image retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately short and front-loads the output type and supported scopes. Some sentences are fragmentary or slightly awkward, but there is little wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the parameter count, full schema coverage, and absence of an output schema, the description provides enough context: it explains the return format, rendering behavior, and cost tradeoff between scoped images and full pages. Minor details such as error behavior are omitted but not essential for calling the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already well documented in the input schema. The description adds some context about max_px and the relative cost of full-page images, but does not provide additional parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource and output: the original page content as a PNG image, covering an element, caption, region, or full page. It does not explicitly contrast itself with sibling tools like get_element_text, but the image-specific purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful guidance on scope selection: prefer element, caption, or region because a full page costs more input, and use a full page when a table fills the page. It does not explicitly say when to choose this tool over text-based siblings, but the guidance for choosing image scope is clear.

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