Skip to main content
Glama

Split PDF

pdf_split
Read-onlyIdempotent

Split a PDF into separate files by page ranges, every N pages, or one file per page, writing the results to a chosen folder for easy distribution or processing.

Instructions

Split one PDF into several PDFs written to a folder: by page ranges (one file per range, e.g. "1-3, 4-6, 7-"), every N pages, or one file per page. Files are named like the website: -pages-1-3.pdf, -part-01.pdf, -page-001.pdf. Use pdf_extract_pages to get a single PDF with chosen pages. Web version: https://s3eidat.github.io/pdf-split/

Input Schema

NameRequiredDescriptionDefault
fileYesThe PDF: a local file path (absolute, or relative to the server's --root) or base64 data (raw or a data: URI).
modeYes"ranges": one PDF per range in `ranges`; "every": a new PDF every `every` pages; "single": one PDF per page.
everyNoFor mode "every": pages per file (e.g. 2 makes 1-2, 3-4…).
outputNoFolder to write the PDFs into (created if missing). Default: a new folder in the server output folder.
rangesNoFor mode "ranges": comma-separated ranges, each becomes one PDF, e.g. "1-3, 4-6, 7-".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations give readOnly/idempotent/openWorld, but the description adds the behavior that matters most here: files land in a destination folder and follow deterministic naming (<name>-pages-1-3.pdf, <name>-part-01.pdf, <name>-page-001.pdf). Note a mild tension: annotations say readOnlyHint=true while the tool creates output files, though it does not modify the input PDF.

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 core action and modes in one dense sentence, then the alternative, then the naming detail. The trailing web-version URL is the only content that doesn't help an agent invoke the tool.

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?

Five parameters at full schema coverage, no output schema, and the description covers modes, destination, and output naming, which is what an agent needs to call it correctly. Edge behavior (invalid or overlapping ranges, what happens when a range exceeds page count) is left undocumented, but that is a minor gap.

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 100%, so baseline is 3. The description goes beyond it by tying each mode to the resulting filename pattern, which is real added meaning about how `ranges`, `every`, and `single` manifest in output. The default output folder behavior is also echoed usefully.

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 (split one PDF into several PDFs written to a folder) and enumerates the three modes with concrete examples. It explicitly distinguishes itself from the sibling pdf_extract_pages, so an agent can choose between them 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 Guidelines4/5

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

"Use pdf_extract_pages to get a single PDF with chosen pages" is an explicit alternative with the selecting condition (one output vs many). Mode selection is implied by the mode semantics and by the examples. It stops short of a full when-not rule (e.g. use pdf_organize to reorder rather than split), so it is clear but not exhaustive.

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