pdfnative-mcp

Extract pages into one PDF

extract_pages

Idempotent

Create one fresh PDF from selected 0-based pages, preserving their given order. Use it to pull page subsets from a source PDF.

Instructions

Keep an arbitrary pages[] subset (0-based, in the given order) in ONE fresh PDF. Same page-tree caveats as merge_pdfs (signatures/AcroForm/XMP dropped; boxes kept; URI links unless dropAnnotations). Encrypted sources: password; output unencrypted unless encrypt. Need several documents? Use split_pdf.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`pages`	Yes	0-based page indices to keep, in output order. Duplicates and out-of-range indices are rejected.
`encrypt`	No	Re-encrypt the output (Standard Security Handler; AES-128 default or AES-256; RC4 never emitted).
`password`	No	Password (user or owner) of an encrypted source. Never logged or echoed.
`pdfBase64`	Yes	Base64-encoded source PDF. Pass `password` for an encrypted source.
`outputMode`	No	'base64' (default) returns the PDF inline; 'file' writes it inside the PDFNATIVE_MCP_OUTPUT_DIR sandbox (SECURITY_VIOLATION when the sandbox is not configured).	base64
`outputPath`	No	Required when outputMode='file'. Relative path inside the sandbox; must end with .pdf (no absolute paths, no '..').
`dropAnnotations`	No	When true, drop ALL annotations. Default keeps self-contained URI link annotations.
`maxOutputSizeBytes`	No	Maximum size, in bytes, of the produced PDF. Defaults to 268435456 (256 MiB).

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes
`summary`	No	Tool-specific summary, when produced.
`filePath`	No	Sandboxed absolute path (file mode).
`sizeBytes`	Yes
`diagnostics`	No	Engine diagnostics (when includeDiagnostics=true).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.2Sep 27, 2026

changedOutput schema / properties / diagnostics / description

Previous value: -"PDF/A diagnostics (when includeDiagnostics=true)."New value: +"Engine diagnostics (when includeDiagnostics=true)."

AddedAug 24, 2026
Removedv1.6.0Jul 22, 2026
Addedv1.2.2Jul 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare read/write/idempotency hints, but the description adds concrete lossy behavior: signatures, AcroForm, and XMP are dropped; boxes are kept; URI links are preserved unless dropAnnotations. It also discloses that output is unencrypted unless `encrypt` and that encrypted sources need `password`.

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?

Four compact clauses front-load the core behavior and bury constraints in parentheticals with minimal waste. It is dense but each sentence carries real information; slightly terse cross-references keep it from a full 5.

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?

With an output schema present, return values need not be explained, and the description covers the mutation profile, source-encryption handling, output-encryption default, annotation retention, and the sibling alternative. Nothing needed to invoke it correctly is missing.

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 description coverage is 100%, so the schema already documents every parameter, and this is the baseline case. The description reiterates `pages`, `password`, `encrypt`, and `dropAnnotations` but adds little syntax or constraint detail beyond what the schema provides.

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 states a specific verb+resource: keep a `pages[]` subset in ONE fresh PDF, with 0-based ordering semantics. It also discriminates from the sibling split_pdf by naming the multi-document case as its opposite, so the agent can distinguish it without opening either 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?

It explicitly routes the agent: 'Need several documents? Use split_pdf.' It also constrains input handling ('arbitrary pages[] subset') and references merge_pdfs for shared caveats, giving clear when-to-use context.

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