Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

resize_pages

DestructiveIdempotent

Change PDF pages to a standard paper size or custom dimensions, scaling each page's content to fit and centering it with proportions kept.

Instructions

Change pages to a paper size (a3, a4, a5, letter, legal, tabloid) or a custom width and height in unit "pt", "in" or "mm", scaling each page's content to fit (proportions kept, centred). orientation "auto" keeps each page's own (landscape pages get a landscape sheet), or force "portrait"/"landscape". Links, form fields and comments move with the content (ones outside a crop stay hidden); scroll positions of bookmarks and links that point into resized pages are not adjusted. Needs the owner password if the PDF forbids changes, or forbids changing comments and pages being resized have any. Signed PDFs are refused.

Any password argument can be "ask": the user then types it on a local page, so it never passes through the chat.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_path": "<input_path>"
    },
    "name": "resize_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNo
unitNopt
pagesNo
widthNo
heightNo
passwordNo
overwriteNo
input_pathYes
orientationNoauto
output_pathNo

Output Schema

NameRequiredDescriptionDefault
pagesYes
widthYes
heightYes
outputYes
scalesYes
password_protectedYes
user_password_changedYes
permissions_restrictedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations (destructive=true, idempotent=true), the description discloses substantive behavior: content is scaled with proportions kept and centred, links/form fields/comments move with content while out-of-crop ones stay hidden, bookmark and link scroll positions are not adjusted. It also states the auth prerequisite and that signed PDFs are refused, plus the 'ask' password mechanism that keeps secrets out of chat.

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 text is front-loaded with the core action and enumerations, then layers constraints and edge cases in descending priority; nearly every clause adds actionable information. It runs slightly long and the clause about the owner password when comments/pages are locked is grammatically tangled, costing a bit of parseability.

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?

For a 10-parameter mutation tool, the definition covers the risky and non-obvious aspects well: scaling semantics, orientation behavior, permission requirements, refusal on signed PDFs, and the safe password mechanism. The main gap is the unaddressed pages selection and overwrite parameters, which matter for a destructive page operation; return values are covered by the existing output schema.

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

Parameters4/5

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

With 0% schema description coverage, the description must carry parameter meaning, and it does for the key ones: size enumerations, unit values (pt/in/mm), custom width/height, orientation auto vs portrait/landscape, and password accepting "ask". It leaves pages, overwrite, input_path and output_path unexplained, including the accepted format for the pages range.

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 opens with a specific verb and resource: 'Change pages to a paper size (a3, a4, a5, letter, legal, tabloid)' or custom width/height, with content scaled to fit. This distinguishes the operation from sibling page tools like crop_pages or rotate_pages by implication (scaling, not cropping or rotating), though no sibling is named explicitly.

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

Usage Guidelines3/5

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

It gives clear operational conditions — owner password needed when changes are forbidden, signed PDFs refused, and the 'ask' password flow — which tells the agent when the call can proceed or fail. However, it never states when to choose resizing over alternatives such as crop_pages or convert_to_pdf, leaving the comparative decision to inference.

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