Skip to main content
Glama
Paperboy

Paperboy

Official
by sudostash

add_page_numbers

DestructiveIdempotent

Stamp sequential page numbers or Bates-style IDs onto PDF pages, choosing format, start value, position, and page range for legal or archival documents.

Instructions

Add page numbers, or Bates numbers for legal documents (format="ACME-{n:06}").

format uses {n} (required), {total} and zero padding like {n:06}. Page k shows n = k + start - 1, so start=0 with pages="2-" skips a cover page and numbers the next page 1. position: top-/bottom- left/center/right (default bottom-center). Needs the owner password if the PDF forbids changes. 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": "add_page_numbers"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoblack
pagesNo
startNo
formatNoPage {n} of {total}
marginNo
passwordNo
positionNobottom-center
font_sizeNo
overwriteNo
input_pathYes
output_pathNo

Output Schema

NameRequiredDescriptionDefault
pagesYes
outputYes
last_labelYes
first_labelYes
password_protectedYes
user_password_changedYes
permissions_restrictedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real context beyond them: the owner-password requirement when a PDF forbids changes, outright refusal of signed PDFs, and the security-relevant 'ask' mode that keeps the password out of the chat. It does not describe what happens to an existing output file when overwrite is unset, a minor gap for a destructive 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?

Front-loads the core purpose and Bates use case, then packs parameter semantics and preconditions into two dense paragraphs with no filler. The embedded second paragraph about the 'ask' password mode is slightly tangential to numbering but earns its place as a security note.

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?

For an 11-parameter mutation tool with an output schema, the description covers the non-obvious semantics (numbering math, format tokens, position values) and the critical preconditions. The remaining undocumented parameters are conventional styling/path fields that don't jeopardize a correct call.

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?

Schema coverage is 0%, so the description must compensate, and it does substantial work: it explains {n}/{total}/zero-padding in format, the start-offset arithmetic (n = k + start - 1), the pages range syntax, and all valid position values with the default. It leaves color, margin, font_size, output_path, and overwrite unexplained, but those are largely self-describing.

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 and resource (add page numbers) and extends it to the legal Bates-numbering use case with a concrete example format. An agent can immediately tell this apart from add_watermark or n_up without opening the schema.

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?

Gives strong conditional guidance for parameters (pages="2-" with start=0 to skip a cover page, 'ask' for passwords) and states prerequisites (owner password needed, signed PDFs refused). However, it never says when to use this versus the sibling add_watermark, leaving the tool-selection decision implicit.

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