Skip to main content
Glama
theluckystrike

mcp-office-suite

by theluckystrike
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

Split a PDF into several files

pdf_split

Split a PDF into multiple files by specifying page ranges (e.g., '1-3,5-'). Preserves the original file; each range becomes a separate PDF.

Instructions

Call this tool to write one new PDF per range. Ranges are 1-based and may be open-ended: "1-3,5,7-" gives pages 1-3, page 5, and 7 to the end. The input is never modified. Free tier: files up to 30 pages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesThe PDF to split
rangesYesComma-separated 1-based page ranges, e.g. "1-3,5,7-". An open-ended range runs to the last page
overwriteNoReplace existing outputs. Default false: nothing is overwritten and nothing is written at all if any target exists
out_path_patternYesOutput path with a placeholder: {n} is the part number (1, 2, 3...), {range} is the range itself (e.g. 1-3), {name} is the input file name without .pdf. Example: ~/out/{name}-{range}.pdf

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4.8/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: it discloses that the input is never modified, that it writes one new PDF per range, that overwrite defaults to false, and that nothing is written if any target exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the action, and uses compact examples. No redundant sentences.

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 a 4-parameter tool with no output schema, the description is complete: it defines range syntax, output naming with placeholders, overwrite behavior, and constraints. An agent has enough information to call it correctly.

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 coverage is 100% and every parameter has a meaningful description: ranges syntax, overwrite default, and out_path_pattern placeholders with an example. This exceeds the baseline for covered parameters.

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?

The description explicitly says 'write one new PDF per range', a specific action on a specific resource, and the 1-based range examples make the split behavior unambiguous. This distinguishes it from siblings such as pdf_merge and pdf_reorder.

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?

It clearly states when to call the tool ('to write one new PDF per range') and gives a concrete range example. It does not explicitly contrast with alternative PDF tools, so it falls short of 5.

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

Install Server

Other Tools