PaperPilot Gives Your AI Agent Local PDF Tools You Can Check by Hand

A new open-source Rust toolkit puts the same PDF engine behind an MCP server, a CLI and a local API. Here's how to set it up, and what to check first.

PDFs are where a lot of tidy agent workflows get messy.

Ask a coding agent to merge two contracts, compress a scan or pull a table out of a report, and it often improvises: it writes a one-off script, installs whatever PDF library it remembers, and runs it. Sometimes it works. When it doesn't, you have a half-broken file and a script you never meant to keep. And if the agent reached for an online converter instead, your document just left the building.

PaperPilot is a young open-source project that takes a different route. It is a PDF and document toolkit written in Rust, and the same engine runs five ways: as an MCP server your agent can call, a command-line tool, a browser tool (built with WebAssembly, so it runs inside the browser tab), a desktop app and a local REST API. Version 0.6.1 went out as a GitHub pre-release on October 26, 2026, the same day the project hit the Hacker News front page.

The interesting part is not any single feature. It is that the agent and you are driving the same engine. Anything your agent does to a PDF, you can run again yourself, with the same tool, on the same file, and compare. That turns the agent's report from "trust me" into "rerun me."

What PaperPilot is, in plain terms

MCP (Model Context Protocol) is the standard way coding agents like Claude Code, Codex and Cursor plug into outside tools. An MCP server is a small program that tells the agent "here are the actions I offer" and then does the work when the agent asks. PaperPilot's MCP server, paperpilot-mcp, runs as a local process on your machine, started by your agent, talking over standard input and output (stdio). No model-provider key needed; the project's agent guide says each agent handles its own model sign-in.

What can it do? The README groups it into five buckets:

Organize and lay out: merge, split, rotate, delete, reorder and extract pages, plus booklet, N-up (several pages printed on one sheet) and poster layouts.
Optimize: lossy compression and removing duplicate data inside the file.
Extract: structured text, Markdown tables and OCR (reading text from scanned pages), done in pure Rust with PaddleOCR models.
Security: watermarking, checking and removing signatures, a PII scan (looking for personal data like names and ID numbers) and a "deep sanitize."
Office data: Excel to JSON or CSV.

The project's own benchmark report says it tested 44 tools across the CLI, MCP and REST interfaces, with all 132 calls succeeding. Hold onto that report; it comes up again in the limitations.

The privacy pitch is short: "Files never leave your machine," and "No Chromium, no C++ runtime, no cloud calls." The Community Edition in the repo is Apache 2.0. An Enterprise Edition with SSO, role-based access, audit logs and data-loss prevention "is developed separately."

Why "same engine, five doors" matters

Here is the idea worth taking away, even if you never install this.

When an agent edits a file with a tool only it can call, you are stuck trusting its report. "I merged the files and compressed the result" is a sentence, not a receipt. When the agent's tool is also a CLI on your path, the report becomes something you can check. Run the same merge yourself. Compare page counts and file sizes. If they match, you trust the agent a little more for good reasons. If they don't, you found the problem before the client did.

Think of it like a calculator your accountant uses. If you can borrow the same calculator, you can check any line of the return. If the accountant has a private one, you take their word for it.

That is the shift PaperPilot points at: agent tools that double as human tools turn agent output from "trust me" into "rerun me."

Three jobs it fits today

You don't need a grand document pipeline to get value from this. Three small jobs show up in almost every builder's week.

Shrinking files before they go anywhere. Scans from a phone or a copier are huge. Telling your agent "compress everything in ./invoices to quality 75 and put the results in ./out" is a one-line request, and the matching paperpilot compress command lets you spot-check any file it produced.

Turning reports into text an AI can read. If you feed PDFs into a retrieval setup (RAG, where a model looks up passages from your documents before it answers), the hard part is getting clean text and tables out first. PaperPilot extracts structured text and Markdown tables locally, so the raw document never has to touch a hosted parser.

Cleaning a file before you share it. Watermarking, stripping signatures, running the PII scan and the "deep sanitize" all sit in the same toolbox. That's a sensible pre-flight step before a document goes to a client or into a shared drive, with the caveat in the limitations below: test the PII scan on your own files before you rely on it.

Put this into practice

The quickest route is the prebuilt MCP server. Each GitHub release ships paperpilot-mcp alongside the paperpilot CLI, the paperpilot-gateway REST server, a desktop bundle, a WebAssembly package and an Android APK, with SHA-256 checksums. Check the checksum before you run it.

Claude Code. From your project folder, using the absolute path to the binary:

claude mcp add --transport stdio --scope project paperpilot -- "/absolute/path/to/paperpilot-mcp"
claude mcp get paperpilot

That writes the project's .mcp.json. Use --scope user instead if you want it in every project. Start a new session, run /mcp, and approve the server when Claude Code asks.

Codex.

codex mcp add paperpilot -- "/absolute/path/to/paperpilot-mcp"
codex mcp list

Then start a new Codex session and check /mcp. The guide warns that in headless Codex runs, a pending tool approval cannot be answered if the approval policy is never (the setting where Codex never stops to ask), so approve interactively the first time.

Cursor and others. Source builds can print a config snippet with paperpilot-mcp --client-config cursor (it also knows codex, claude-code, kimi-code, pi and claude-desktop). It prints; it does not edit your settings, so merge the entry by hand and keep your existing servers.

One gotcha the guide calls out: the server only sees files where it runs. If your agent works inside a container, WSL (Windows Subsystem for Linux) or an SSH session, install PaperPilot there and use paths from that environment.

Your first real test. Pick two PDFs you don't mind experimenting with. Ask your agent to merge them into one file. Then do the same merge yourself with the CLI:

paperpilot merge --inputs doc1.pdf doc2.pdf --output merged-by-hand.pdf

Open both outputs. Same page count, same order? Good. That small habit is the whole value of the design. The README shows two more commands worth trying the same way:

paperpilot compress --input in.pdf --quality 75 --output compressed.pdf
paperpilot rotate --input in.pdf --pages 1,3-5 --angle 90 --output out.pdf

If you'd rather call it from code, run paperpilot serve --port 7823 and open /swagger-ui on that port for the API docs. Everything stays on localhost.

If you want to build from source instead, the README says Rust 1.75 or newer, but the v0.6.1 CLI manifest declares edition = "2024", which needs Rust 1.85 or newer. Use a current toolchain:

cargo build --release -p paperpilot-cli -p paperpilot-mcp -p paperpilot-gateway

Honest limitations

This is a young project with about 630 GitHub stars as of October 27, 2026, and it reads like one. Go in with your eyes open.

The speed claims are thin. The README's benchmark section is an empty placeholder; the source still holds a TODO comment asking for "a real table: operation | input size | time | machine." A "sub-5ms" label sits on the ingestion feature with no method attached. The separate benchmark report, written by the project itself, does have numbers, but look at the inputs: its "large" test PDF is 20 pages and 4,737 bytes. A real scanned contract can easily run to several megabytes. Fast on toy files tells you little about your 300-page scan.

"No cloud calls" has an asterisk. The native binaries make that promise. The browser embed does not fit it so neatly: the README's snippet loads embed.js from cdn.usepaperpilot.com, the project's own server. The README says files in the browser are "processed in browser memory, nothing is uploaded," but the code doing the processing still comes from someone else's server each time. If privacy is why you're here, use the CLI or MCP server.

Some things are undocumented. The README doesn't say whether the OCR models download on first use or from where, and it doesn't explain how the PII scan decides what counts as personal data. Test both on your own documents before trusting them with anything sensitive.

It moves fast, and nothing is stable yet. Three releases landed in a week, and GitHub marks all three as pre-releases: v0.5.0 on October 20, v0.6.0 on October 24 and v0.6.1 on October 26. The MCP setup for Codex, Claude Code, Kimi Code and Pi arrived in v0.6.1 from a first-time contributor. Pin the version you tested, and re-run your merge comparison after each upgrade.

The tool list is something you discover. The agent guide names only pdf_merge explicitly. Use your client's /mcp view to see what your build actually exposes before you write prompts that assume a tool exists.

Open core. SSO, access control, audit logs and data-loss prevention live in the separate Enterprise Edition. If your company needs any of those, the free repo will not cover it.

None of this is a reason to skip it. It is a reason to treat it like the version number says: 0.6.

Where this leaves you

The best thing about PaperPilot is a habit it makes easy, not a feature. When your agent touches a document, you should be able to do the same thing yourself and get the same file. This tool hands you that for PDFs, locally, with one binary.

Try it on two throwaway files this week. If the agent's merge matches yours, add it to your setup. If it doesn't, you just learned something about your agent that its own report would never have told you.

Sources: PaperPilot README and coding-agent setup guide on the main branch as of October 27, 2026; PaperPilot releases (v0.6.1 reviewed); SYSTEM_BENCHMARK_REPORT.md.