PaperPilot, a PDF and document toolkit written entirely in Rust, now ships five interface surfaces off a single engine: MCP server, CLI, browser WASM build, a Tauri desktop app, and a local REST API — with the explicit design claim, per the project's GitHub repository, that files never leave the machine running it.
The architecture is the pitch. According to the repository, the project runs "the same engine" as an MCP stdio server, a CLI for batch workflows, a WASM build that processes files "in browser memory, nothing is uploaded," a Tauri plus Svelte desktop GUI, and a local REST API reachable at localhost:7823. The core is split into workspace crates — paperpilot-core, paperpilot-pdf, paperpilot-nlp, paperpilot-gateway, paperpilot-mcp, paperpilot-wasm, and paperpilot-storage — built on lopdf, pdf_oxide, and rten, which the repository names as the libraries behind the engine. The README states plainly: "No Chromium, no C++ runtime, no cloud calls."
For teams wiring document-grounded agents, the MCP path is the operational center of the pitch. The repository lists Codex, Claude Code, Kimi Code, Pi, Claude Desktop, and Cursor as clients that connect to the same local stdio server, and the binary paperpilot-mcp can print client-specific configuration directly — the README shows `paperpilot-mcp --client-config codex` as an example, with claude-code, kimi-code, pi, claude-desktop, and cursor given as the other supported targets. For Claude Desktop, setup is a config file pointing at the local binary path, after which the README's example prompt is: "Merge these two PDFs and compress the result."
The REST surface is pitched specifically at Open-WebUI and Apache Tika-style ingestion pipelines, exposing /tika/text, /tika/json/md, and /rmeta/text endpoints. The repository's Extract & Ingest feature list names this Open-WebUI and Apache Tika ingestion adapter and, as a separate item in that same list, "pure-Rust OCR (PaddleOCR via rten)" — the two are listed side by side rather than described as one combined feature. The one concrete latency figure in the material is narrow but specific: the repository's own curl example for the /tika/text endpoint is labeled "In-Memory Ingestion (sub-5ms)." There is no broader benchmark figure in the material beyond that — the repository points to a separate SYSTEM_BENCHMARK_REPORT.md and a `cargo bench --workspace` command for reproducing results, but does not publish throughput, memory, or cost numbers in the text available here.
As of the version documented in the repository, v0.6, the feature set spans page organization (merge, split, rotate, delete, reorder, extract, booklet imposition, N-up grid, poster tiling), compression (described as lossy compression with stream deduplication and CMYK safety guards), extraction (structured text, detected Markdown tables, the Tika-compatible ingestion adapter, and OCR), and a security tier covering watermarking, signature validation and removal, PII scanning, deep sanitization, and what the README calls "malformed fuzzing & panic-free error handling." An Office Data module handles Excel-to-JSON and Excel-to-CSV conversion.
What the material does not resolve is scale under production load. The repository gives no numbers for concurrent request handling, memory ceilings on large or malformed PDFs, or OCR accuracy — the PaddleOCR-via-rten pipeline is named but not benchmarked in the text provided. The licensing split is also a structural caveat for any team planning to depend on this: the Community Edition in the public repository — CLI, MCP server, REST gateway, WASM engine, and desktop app — is Apache 2.0, but SSO, RBAC, audit logs, and DLP are gated behind a separately developed Enterprise Edition, meaning the governance controls a regulated deployment would likely want are not part of the open build.
The liftable pattern here is narrower than "zero-cloud PDF processing": it's a single Rust core compiled once and exposed through MCP, REST, and WASM bindings so that a document tool behaves identically whether an agent calls it over stdio or a user drags a file into a browser tab. Teams building document-grounded agents through MCP should treat the sub-5ms ingestion number as a narrow, single-endpoint claim, not a system-wide benchmark, and should check whether the audit and access controls they need are inside the Apache 2.0 Community Edition or gated behind the separate Enterprise license before they wire it into anything regulated.