benspdf

Overview Schema Source Related Servers Discussions Admin

pdf_page_layout

Measure PDF page sizes, orientation, and rotation, grouping pages by shape to reveal mismatched or sideways pages without reading page content.

Instructions

Measure a PDF's page sizes, orientation and rotation.

Answers "what size is this, is it all the same, and why does one page come out sideways?". Reads page geometry only, so it stays cheap on long documents.

sizes groups the pages by shape, most pages first, each carrying the page numbers it covers as a range like "1-16,18", so a 300 page document answers in one entry instead of 300 rows. Sizes are the page as a reader sees it: CropBox clipped to MediaBox with /Rotate applied, so a landscape box rotated 90 degrees reports as portrait. Pages within 3pt of a known paper are grouped and named together, since real A4 varies by a millimetre.

Pass pages for per page rows carrying the raw boxes: "1-20", "3", "1,5,9-12" or "all", capped at 100 rows.

It does not look at page content; for whether the pages hold readable text use pdf_check_text.

Args: ref: PDF file path, or a workspace artifact id. pages: Optional page range for per page detail. Omit for groups only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ref`	Yes
`pages`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Sep 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it discloses that only geometry is read (implying a cheap, non-mutating operation), the group-vs-row behavior, the CropBox-to-MediaBox + /Rotate normalization, a 3pt paper-size tolerance, and a 100-row cap on per-page output.

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?

Front-loaded with the one-line purpose, then grouped and per-page behavior, then the sibling exclusion, then args. It is denser than strictly required (the A4-variation aside could be trimmed), but virtually every sentence conveys actionable detail rather than filler.

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

Completeness5/5

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

An output schema exists, so return-shape explanation is not required; the description supplies everything else needed to call it correctly, including grouping semantics, range syntax, the row cap, and the boundary against the text-checking sibling.

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

Parameters5/5

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 and does: `ref` is defined as a file path or workspace artifact id, and `pages` accepts documented range syntax ("1-20", "3", "1,5,9-12", "all"), is capped at 100 rows, and is optional with a stated default of groups-only.

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

Purpose5/5

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

States a specific verb+resource: measure a PDF's page sizes, orientation and rotation. It explicitly demarcates scope from siblings by naming pdf_check_text for content/readability questions, so an agent can distinguish it from pdf_metadata and pdf_render_pages without opening a schema.

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

Usage Guidelines5/5

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

Frames the use case as three concrete questions (what size, is it all the same, why sideways) and routes the content case to pdf_check_text. It also gives an explicit when-to-use-the-`pages`-param rule (omit for groups only, pass for per-page rows).

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

Deploy Server