Skip to main content
Glama
Sign In

pdfops-mcp

by dev.pdfops
OverviewDiscussionsAdmin

Split PDF into parts

pdf_split
Idempotent

Split one PDF into several PDFs, either by explicit ranges (each comma group becomes one part: "1-2,3-5" gives two parts) or into fixed-size chunks (every=2 on 5 pages gives 1-2, 3-4, 5). Give exactly one of ranges or every. Returns each part inline as an application/pdf resource plus a structured parts list (pages, page_count, bytes, resource_uri). Limited to 100 parts and about 4 MB of total output; use pdf_extract_pages for a single range.

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": {
      "pdf_path": "<pdf_path>"
    },
    "name": "pdf_split"
  }
}

Input Schema

NameRequiredDescriptionDefault
everyNoChunk size in pages; the last part may be shorter
rangesNo1-based page spec; each comma group becomes one part, e.g. "1-2,3-5"
passwordNoPassword to open the input, only needed for a user-password PDF (owner-locked files with an empty user password open without it).
pdf_pathYesPDF source: an https:// URL or a data:application/pdf;base64,… URI (this hosted server cannot read local file paths).

Output Schema

NameRequiredDescriptionDefault
countYesNumber of parts produced
partsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare safety/idempotency; the description adds hard operational limits (100 parts, ~4 MB total output) and describes the return shape (inline application/pdf resources plus a structured parts list with pages, page_count, bytes, resource_uri). It also warns that the hosted server cannot read local paths, which is a real behavioral constraint an agent must know before calling.

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?

Front-loaded with the core action and both modes, then constraints, then return shape, then the sibling pointer. Parenthetical examples are the only elaboration and each one clarifies a parameter rather than restating it.

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 an output schema, the description covers mode selection, limits, output form, and input source restrictions — everything an agent needs to invoke correctly. Nothing material is left to inference.

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 the baseline is 3, but the description adds the mutual-exclusivity constraint that the schema itself does not encode (no oneOf), and concrete examples ('1-2,3-5' → two parts, every=2 on 5 pages → 1-2, 3-4, 5) that make the parameter interaction unambiguous.

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') and immediately enumerates the two operation modes, so an agent can tell it apart from pdf_extract_pages and pdf_merge 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 Guidelines5/5

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

Explicit selection rule ('Give exactly one of ranges or every') plus an explicit alternative for the adjacent case ('use pdf_extract_pages for a single range'). Both the when-to-use and when-to-use-something-else conditions are named.

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

All pdfops-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources