PaperPilot v0.6 gives Anthropic’s Claude Desktop and Cursor a local route to merge, split, OCR and compress PDFs through the Model Context Protocol, or MCP. Announced on October 26, 2026, the project packages familiar document operations into an Apache-2.0 toolkit that can run without a cloud PDF-processing service, according to its repository documentation.
The practical appeal is straightforward: an agent can invoke document tools on your machine instead of sending a file to an online PDF utility. The same Rust core also supports a command-line interface, a browser WebAssembly build, a desktop application and a local REST API.
Two boundaries matter before connecting it to sensitive documents. Local PDF processing does not automatically make the attached AI client entirely offline. And the README’s explicit v0.6 feature list is narrower than some claims in the creator’s launch post, particularly around signing, redaction and document conversion.
One Rust Core, Five Ways to Work With Documents
PaperPilot’s architecture puts a shared Rust engine behind five interfaces. The README describes them this way:
| Interface | Documented use | Practical fit |
|---|---|---|
| MCP server | Connect Claude Desktop, Cursor and other MCP clients to PDF tools | Agent-directed document tasks |
| CLI | Run document operations through commands | Scripts and repeatable batch workflows |
| Browser WASM | Process files in browser memory without uploading them | Zero-install, interactive tasks |
| Desktop app | Tauri and Svelte interface with a viewer, markup and diff | Graphical document work |
| Local REST API | Call the engine at localhost:7823 from tools such as Python, Node or n8n | Application and workflow integration |
WebAssembly lets the browser run the compiled processing engine inside the browser environment. MCP serves a different purpose: it exposes operations as tools an AI client can request. The REST interface gives conventional applications an HTTP route into the engine.
I’d treat this interface reuse as PaperPilot’s most useful contribution. Merging a PDF is already a well-served task; making a local engine accessible to both an agent and an ordinary script reduces the integration work around it.
A shared core is an architectural benefit, though it is not proof that every operation has an identical interface or is exposed everywhere. The documentation describes the five access routes without providing a complete feature-parity matrix.
The Shortest Claude and Cursor Setup
PaperPilot’s documented MCP quick start uses a downloaded executable, so getting an agent connected does not require building the whole Rust workspace.
For Claude Desktop, the project’s instructions are:
- Download
paperpilot-mcpthrough the repository’s Releases link and save it locally. - Add its executable path to
claude_desktop_config.json. - Restart Claude Desktop.
The configuration has this structure:
{
"mcpServers": {
"paperpilot": {
"command": "/path/to/paperpilot-mcp"
}
}
}
Replace /path/to/paperpilot-mcp with the actual absolute path to the downloaded executable. If the configuration already contains other MCP servers, add the paperpilot entry alongside them instead of replacing the file.
For Cursor, the same configuration structure belongs in its mcp.json configuration. Cursor’s MCP documentation supports local command-based servers and describes their transport as stdio: the client starts a process and exchanges protocol messages through standard input and output.
That means the direct executable setup does not require starting the REST gateway or configuring an HTTP endpoint. Cursor also lets users manage MCP servers through its Customize page.
Once the server is connected, ask the agent to merge two local PDFs and compress the result, supplying the relevant file paths. Start with non-sensitive copies and check the output before using the workflow on important documents. That is a sensible adoption step for an early document-processing tool, especially when an agent is choosing operations on your behalf.
What Version 0.6 Actually Includes
The README groups the shipped v0.6 capabilities into organization, optimization, extraction, security and Office-data operations. Its current feature inventory includes:
- Page organization: merge, split, rotate, delete, reorder and extract pages, plus booklet imposition and N-up grids.
- Compression: reduce PDF size through the engine’s compression operation.
- Text extraction: extract existing PDF text or run OCR, documented as pure-Rust PaddleOCR through
rten. - Security-related utilities: watermarking, signature validation, signature removal, personally identifiable information scanning and deep sanitization.
- Spreadsheet conversion: Excel to JSON and Excel to CSV.
Booklet imposition arranges pages for booklet printing. N-up layouts place multiple document pages on one output page. These are useful print-preparation operations beyond the basic merge-and-split workflow.
Text extraction and OCR also solve different problems. A PDF containing selectable text may allow direct extraction. A scanned page is an image, so OCR must recognize the characters first. The feature listing does not by itself promise a particular OCR accuracy level or guarantee a searchable text layer in the resulting PDF.
The CLI provides a direct route to the same kind of work. This documented example merges two inputs into a new file:
paperpilot merge --inputs doc1.pdf doc2.pdf --output merged.pdf
The command names the inputs explicitly and writes the result to merged.pdf. It is a setup example from the documentation, not a command executed for this article.
I’d use the CLI first for a fixed, recurring operation. Explicit arguments are easier to inspect and reuse than a natural-language request. MCP becomes more useful when the task involves choosing or combining operations as part of a larger agent workflow.
Local Processing Has a Specific Privacy Boundary
PaperPilot says its browser build processes documents in browser memory with no file uploads. Its README also describes the toolkit as requiring no cloud calls. Those are claims about PaperPilot’s processing path, and they explain the project’s zero-cloud positioning.
An attached AI client introduces another data path.
An MCP server exposes tools and returns results to its host. If an agent requests extracted text, that text can become available to the client for the next stage of the task. Whether it then reaches a remote model depends on the client, model configuration and workflow. PaperPilot’s local execution cannot answer that question by itself.
The useful distinction is between keeping PDF processing local and keeping the entire AI interaction local. PaperPilot documents the first. The supplied evidence does not establish the second for a connected Claude or Cursor session.
For confidential work, I’d check what the host sends to its model provider before asking it to read or summarize document contents. A task that only merges named files has different data needs from one that extracts and reasons over every page.
Local execution can also leave local records. PaperPilot’s Docker documentation describes an embedded database at /data/paperpilot.db that stores asynchronous jobs, audit records and semantic vector chunks. It provides cleanup instructions for job history and indexed chunks.
That persistence is separate from the browser’s in-memory processing claim. It matters because avoiding a cloud upload does not make a local workflow automatically ephemeral.
These privacy and implementation details come from the project’s documentation. The available evidence includes no independent security audit, hands-on verification or independently measured performance results.
Frequently Asked Questions
3 questions
1Does PaperPilot Make Claude or Cursor Fully Offline?
No. PaperPilot documents local document processing. The connected client’s model configuration and data handling determine whether the broader AI interaction uses remote services.
