PaperPilot’s repository documents four MCP operations, merge, split, OCR, and compress, served by a single Rust binary that the project says makes “No Chromium, no C++ runtime, no cloud calls.” If your contracts, invoices, or client PDFs cannot be sent to a document-AI API, that is the practical answer to a question most MCP wiring guides skip: you can give Claude Code, Cursor, or any MCP client real PDF capability without a vendor DPA, because the project says nothing crosses the network boundary from the engine at all. But the same repo puts conversion, office export, signing, and rendering on an unshipped roadmap, and OCR, the operation that matters most for scanned documents, is the one to measure on your own documents before an agent acts on its output. The right decision is therefore not “local or cloud” for the team. It is a routing rule per document type.
Every capability claim about PaperPilot in this article comes from the project’s own repository and is labeled as such. The repo’s benchmark section is first-party: a cargo bench --workspace reproduction command and a pointer to a SYSTEM_BENCHMARK_REPORT.md for methodology and results.
What actually stays on your machine
The privacy argument for a local engine is narrower than it first appears, and getting the boundary right is most of the value.
PaperPilot is a PDF and document toolkit written in Rust, with the same engine exposed across five surfaces: an MCP server for agent clients, a CLI for batch work, a browser WASM build, a Tauri desktop app, and a local REST API at localhost:7823 callable from Python, Node, or n8n (project repository). The repo states that the browser surface processes files “in browser memory, nothing is uploaded,” and the surfaces share one pure-Rust core built on lopdf, pdf_oxide, and rten. The Community Edition covering all of these is Apache 2.0; an Enterprise Edition with SSO, RBAC, audit logs, and DLP is developed separately.
What this changes about your privacy review is the unit of analysis. With a document-AI API, the review is about which vendor’s data processing agreement you can sign, what retention terms it offers, and whether its subprocessors are acceptable. With a local engine, the question shifts to what leaves the process boundary at all. That is a shorter checklist, but it is not empty:
- The engine process. Repo-stated: no cloud calls. The PDF bytes and extracted text stay in the local process (or in browser memory for the WASM surface).
- The MCP transport. A stdio server inherits the parent’s environment and file access; anything you mount or pipe into it is in scope.
- The model client. This is the part people miss. A local PDF engine bounds the engine, not the LLM. If Claude Code or Cursor sends extracted contract text to a hosted model, that text still leaves your machine. “Zero-cloud PDF” does not mean zero-cloud pipeline.
- Governance features. SSO, RBAC, audit logs, and DLP are not in the Apache 2.0 Community Edition; if your compliance review expects them, that is a separate edition, not a config flag.
If your constraint is “the PDF bytes must never be transmitted,” a local engine plus a model configuration that respects the same boundary satisfies it in a way no API contract can. If your constraint is really “we need an audit trail of who touched which document,” the Community Edition alone does not answer it.
Operations the MCP server serves today
The documented current MCP operation set is exactly four verbs: merge, split, OCR, and compress. The repo describes the server as giving “Codex, Claude Code, Kimi Code, Pi, Claude Desktop, Cursor, or any MCP client the ability to merge, split, OCR, and compress PDFs.”
That is a useful but specific toolkit. Merge and split cover the assembly operations agents need constantly: combining an executed agreement with its exhibits, splitting a scanned lease package into per-chapter files before extraction. Compress handles the practical problem of PDFs that blow past upload or context limits. OCR is the load-bearing one for anything scanned, and it is also the operation with the least evidence behind it, which the next sections cover.
Notice what is absent from the MCP surface: text extraction as a first-class operation, table extraction, rendering pages to images, and format conversion. The repo’s v0.6 “today” list is wider on the engine’s other surfaces, including plain-text extraction, rotate, watermark, PII scan, and Excel conversion, but an MCP client gets only the four verbs above. An agent that needs “read this PDF and summarize page 12” is relying on OCR as the text path, or on the model client reading the PDF itself. Table extraction from PDFs is not addressed on the project page reviewed here, and the cited research does not evaluate it; absence from the page is not proof of absence, but you should not design a workflow around it without testing.
Still on the roadmap
The repo’s ROADMAP.md commits to a wider surface, none of it documented as shipped in the snapshot reviewed:
- v0.7: PDF ↔ Markdown / HTML / JSON
- v0.8: PDF → Word / Excel / PowerPoint
- v0.9: encrypt, decrypt, sign, redact, forms, annotations
- v1.0: render, flatten, repair, compare, PDF/A, Bates numbering
Two cautions apply. First, the repo snapshot referenced here is undated relative to this roadmap, so which items have shipped by the time you read this is unverified; check the repository before designing against any of them. Second, the list is revealing about what the current engine is for. Conversion, signing, redaction, rendering, and archival formats (PDF/A, Bates numbering for legal production) are exactly the operations document-heavy legal and finance workflows eventually need. If those are on your critical path today, a local-only PaperPilot deployment does not cover them, and the honest comparison is against a cloud document-AI API or hand-rolled PDF libraries that do.
Where local breaks first
The failure boundary for PDF extraction is documented in the research literature, and it lands directly on the one operation PaperPilot currently offers for content extraction.
A comparative study of parser and OCR technologies on Nepali PDFs, run on five test PDFs across four libraries, found that direct PDF parsing is fast and accurate for Unicode-compatible digital documents. On non-Unicode fonts, the parser extracts an English-letter correspondence for each character that must be converted back through one-to-one mapping, increasing error on the final result. On image-embedded content, it cannot extract the text at all. OCR becomes necessary in both cases, and it carries the entire load for scanned pages. The practical boundary the authors establish: “PDF parsing offers fast and accurate extraction but faces challenges with non-Unicode Nepali fonts. OCR, specifically PyTesseract, overcomes these challenges, providing versatility for both digital and scanned PDFs.” The magnitudes come from Nepali-language documents and may not transfer directly to English invoices, but the structural finding generalizes: digital-native text and everything else are different problems with different error profiles.
The second finding is about what OCR errors do downstream. A framework study on NLP accuracy over OCR documents measured named-entity recognition accuracy dropping at multiple OCR degradation levels, and showed that a text-restoration model trained on degraded data “significantly closes the NER accuracy gaps caused by OCR errors, including on an out-of-domain dataset.” In other words, OCR mistakes do not stay in the extraction step; they propagate into whatever the agent does next, and recovering from them takes a dedicated correction stage. That study also contributes a testing method worth reusing: its Genalog tool synthesizes degraded document images (Gaussian blur, bleed-through, salt-and-pepper noise, morphological effects) at stackable strengths, so you can measure how your own pipeline’s accuracy decays as scan quality worsens rather than discovering it in production.
Applied here: PaperPilot lists OCR as a shipped operation, but “OCR” on a feature list is a capability claim, not a fidelity number. For digital-native PDFs, the parse path in any competent engine is likely fine; for a mixed archive of scanned vendor invoices, the extraction error rate is the whole decision, and it is the number the bounded test below produces.
Ecosystem reality check
The registry census is worth one calibration point here, with the caveat that it measures registry composition, not PDF-tool quality or community maintenance around a deployment pattern.
Among a 400-server random draw of npm/stdio servers from the official MCP registry, a frame the paper notes covered 30.7% of the registry population at its August 2026 snapshot, the 195 servers that completed an initialize handshake (48.8% of draws) advertised 2,766 tools (census), with counts from 1 to a maximum of 300 and a median of 8, and none of those tools carried a fatal JSON Schema violation. PaperPilot’s four-operation MCP surface is lean even by that standard, which is consistent with a focused tool rather than a red flag. These numbers describe registered servers as of August 2026, not how well any particular tool does its job.
Routing per document type
The evidence supports a per-document-type routing rule rather than a per-team commitment. This is an inference drawn from mapping the repo-stated operation set against the measured parse-versus-OCR boundary; it is not a measured equivalence between PaperPilot and any cloud service.
| Workload | Route | Why |
|---|---|---|
| Merge, split, compress of digital-native PDFs | Local (PaperPilot MCP) | Documented current operations; text never crosses the process boundary |
| OCR of digital-native text (embedded fonts) | Local, with spot checks | Parse path is fast and accurate for Unicode-compatible content per the Nepali study |
| Scanned contracts, invoices, faxed exhibits | Cloud or hybrid, until tested | OCR errors measurably degrade downstream NLP; gate the route on a measured accuracy test |
| Non-Unicode font documents | OCR path, fidelity tested per document class | Parsing accuracy drops through error-prone one-to-one mapping; OCR is the fallback in the measured literature |
| PDF ↔ Markdown/HTML/JSON, Office export | Not local yet | Roadmap v0.7–v0.8, not documented as shipped |
| Sign, redact, encrypt | Not local yet | Roadmap v0.9 |
| Render, repair, PDF/A, Bates numbering | Not local yet | Roadmap v1.0 |
| Structured table extraction | Unverified locally | Not addressed on the project page reviewed here |
Before trusting agent output on any document class that depends on OCR, run a bounded test: take a sample of your real scanned documents, degrade copies with a tool like Genalog at a few strengths, and measure whether the downstream task (field extraction, entity recognition, summarization) still meets your bar. That converts an unknown into a number you can route on.
The decision
For documents that cannot leave the machine, serve merge, split, OCR, and compress from PaperPilot’s local MCP server: one Apache 2.0 Rust core, no cloud calls, reachable from any MCP client and from a localhost REST API for non-agent pipelines. Route scanned-heavy, structured-extraction, conversion, and rendering workloads to a document-AI API or a hybrid path until those operations ship and OCR fidelity is tested per document class. Hand-rolling with PDF libraries remains the fallback when you need an operation nobody ships yet, but it trades a single binary for an ongoing maintenance commitment.
I would trial this on document classes that tolerate an extraction mistake, and hold scanned financial documents behind a measured accuracy test before letting an agent act on their contents. The cost argument is real: a local binary removes the API bill and the vendor review, but it transfers the fidelity-testing burden to you, and for OCR-dependent workloads that burden is currently unpaid.
Two limitations bound everything above. First, this article cites no independent OCR accuracy figure for PaperPilot; the repo’s benchmarks are first-party, so treat OCR fidelity as untested until you measure it on your own documents. The repo snapshot’s date relative to its v0.7, v1.0 roadmap is unstated, so which roadmap items have shipped by the time you read this is unverified. Second, the measured failure boundaries come from Nepali-language documents and one NER restoration framework, so their magnitudes may not transfer to your document mix. The routing structure will hold; the error rates you observe will be your own.
Frequently Asked Questions
Which MCP operations does PaperPilot serve today?
The documented current MCP operation set is exactly four verbs: merge, split, OCR, and compress. The repo describes the server as giving “Codex, Claude Code, Kimi Code, Pi, Claude Desktop, Cursor, or any MCP client the ability to merge, split, OCR, and compress PDFs.”
Does the local PDF engine prevent all data from leaving the machine?
The model client. This is the part people miss. A local PDF engine bounds the engine, not the LLM. If Claude Code or Cursor sends extracted contract text to a hosted model, that text still leaves your machine. “Zero-cloud PDF” does not mean zero-cloud pipeline.
What governance features are missing from the Community Edition?
Governance features. SSO, RBAC, audit logs, and DLP are not in the Apache 2.0 Community Edition; if your compliance review expects them, that is a separate edition, not a config flag.
Join the discussion
Share a useful perspective or ask a question about this article.