Skip to main content
Glama
s3eidat

S3eidat Tools MCP

by s3eidat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add page numbers

pdf_page_numbers
Read-onlyIdempotent

Add page numbers, headers, and footers to PDFs with custom formats, positions, page ranges, and cover skipping. Numbers stay upright on rotated pages.

Instructions

Add page numbers to a PDF, plus an optional header and footer line. Format tokens: {n}, {total}, {date}, {filename} (e.g. "Page {n} of {total}", "{n} / {total}", "- {n} -"). Choose the corner/edge, start number, how many leading pages to skip (e.g. a cover), a page range, font, size, colour and margin. Numbers stay upright on rotated pages. Web version: https://s3eidat.github.io/pdf-page-numbers/

Input Schema

NameRequiredDescriptionDefault
dateNoText for {date}. Default: today in the server locale.
fileYesThe PDF: a local file path (absolute, or relative to the server's --root) or base64 data (raw or a data: URI).
fontNoHelvetica
sizeNoText size in points. Default 10.
skipNoLeave this many first pages without a number (e.g. 1 for a cover). Default 0.
colorNoColour as hex "#rrggbb". Default #333333.#333333
pagesNoPages to number: 1-based list like "1-3, 5, 8-" ("5-" = to the end, "-3" = first three, "3-1" = reversed). Also "all", "odd", "even", "last". Empty = all pages.
startNoNumber of the first numbered page. Default 1.
footerNoOptional footer text on numbered pages (tokens allowed).
formatNoNumber format with {n}, {total}, {date}, {filename}. Default "Page {n} of {total}". Empty = no number (header/footer only).Page {n} of {total}
headerNoOptional header text on numbered pages (tokens allowed).
marginNoDistance from the page edge in points. Default 28.
outputNoWhere to write the result: a file path, or a folder ending in "/". Default: the server output folder (a temp folder unless --out-dir is set).
positionNoWhere the number goes: t/b = top/bottom, l/c/r = left/centre/right. Default "bc".bc
footerAlignNoFooter alignment: l, c or r.c
headerAlignNoHeader alignment: l, c or r.c
returnBase64NoAlso return the output as base64 in the result (only for small files). Default false.

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?

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower; the description still adds real context — numbers stay upright on rotated pages, base64 return only works for small files, and output defaults to a server temp folder unless --out-dir is set. It does not say what the success result looks like or whether the input file is preserved (though the separate `output` param implies a new file).

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?

Two tight sentences plus token examples, with the capability stated first and the configuration surface second. The trailing documentation URL is the only element that does not help invocation, but it is harmless and short.

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 17-parameter, write-a-file tool with no output schema, the description covers the full option surface and the default output location. The remaining gap is the return payload (file path vs base64 envelope) when returnBase64 is false, which the agent must infer.

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 coverage is 94%, so the schema already carries nearly all parameter meaning. The description enumerates the same option set (corner, start, skip, range, font, size, colour, margin) and mirrors the format-token examples, adding little beyond what is already documented in the schema.

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?

A specific verb and resource ('Add page numbers to a PDF') plus the extra capability of header/footer lines. An agent immediately knows the outcome, and the token list makes the scope concrete rather than generic.

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?

Usage is implied by the described options (skip a cover, page ranges), but there is no explicit when-to-use guidance and no differentiation from near neighbours such as pdf_watermark, pdf_organize or pdf_metadata_write. The web-version link is not routing guidance for an agent.

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

Deploy Server

Other Tools