PaperPilot, un conjunto de herramientas para PDF y documentos escrito enteramente en Rust, ahora distribuye cinco superficies de interfaz a partir de un único motor: servidor MCP, CLI, una compilación WASM para navegador, una aplicación de escritorio Tauri y una API REST local, con la afirmación de diseño explícita, según el repositorio de GitHub del proyecto, de que los archivos nunca salen de la máquina que lo ejecuta.
La arquitectura es la propuesta. Según el repositorio, el proyecto ejecuta "el mismo motor" como servidor MCP stdio, una CLI para flujos de trabajo por lotes, una compilación WASM que procesa archivos "en memoria del navegador, nada se sube", una GUI de escritorio Tauri más Svelte, y una API REST local accesible en localhost:7823. El núcleo está dividido en workspace crates —paperpilot-core, paperpilot-pdf, paperpilot-nlp, paperpilot-gateway, paperpilot-mcp, paperpilot-wasm y paperpilot-storage— construidos sobre lopdf, pdf_oxide y rten, que el repositorio nombra como las bibliotecas detrás del motor. El README afirma claramente: "Sin Chromium, sin runtime de C++, sin llamadas a la nube."
Para los equipos que conectan agentes basados en documentos, la vía MCP es el centro operativo de la propuesta. El repositorio enumera Codex, Claude Code, Kimi Code, Pi, Claude Desktop y Cursor como clientes que se conectan al mismo servidor stdio local, y el binario paperpilot-mcp puede imprimir configuración específica para cada cliente directamente — el README muestra `paperpilot-mcp --client-config codex` como ejemplo, con claude-code, kimi-code, pi, claude-desktop y cursor como los demás objetivos compatibles. Para Claude Desktop, la configuración consiste en un archivo que apunta a la ruta local del binario, tras lo cual el prompt de ejemplo del README es: "Fusiona estos dos PDF y comprime el resultado."
La superficie REST está orientada específicamente a pipelines de ingesta al estilo Open-WebUI y Apache Tika, exponiendo los endpoints /tika/text, /tika/json/md y /rmeta/text. La lista de funciones Extract & Ingest del repositorio nombra este adaptador de ingesta Open-WebUI y Apache Tika y, como elemento separado en esa misma lista, "pure-Rust OCR (PaddleOCR via rten)" — ambos se enumeran uno junto al otro en lugar de describirse como una función combinada. La única cifra de latencia concreta en el material es acotada pero específica: el propio ejemplo curl del repositorio para el endpoint /tika/text está etiquetado "In-Memory Ingestion (sub-5ms)." No hay ninguna cifra de referencia más amplia en el material más allá de esa — el repositorio remite a un SYSTEM_BENCHMARK_REPORT.md separado y a un comando `cargo bench --workspace` para reproducir los resultados, pero no publica cifras de throughput, memoria o costo en el texto disponible aquí.
A partir de la versión documentada en el repositorio, v0.6, el conjunto de funciones abarca organización de páginas (fusionar, dividir, rotar, eliminar, reordenar, extraer, imposición de folletos, cuadrícula N-up, mosaico de pósters), compresión (descrita como compresión con pérdida con deduplicación de streams y protecciones de seguridad CMYK), extracción (texto estructurado, tablas Markdown detectadas, el adaptador de ingesta compatible con Tika, y OCR), y un nivel de seguridad que cubre marcas de agua, validación y eliminación de firmas, escaneo de PII, saneamiento profundo, y lo que el README llama "malformed fuzzing & panic-free error handling." Un módulo Office Data gestiona la conversión de Excel a JSON y de Excel a CSV.
Lo que el material no resuelve es la escala bajo carga de producción. El repositorio no ofrece cifras sobre el manejo de solicitudes concurrentes, los límites de memoria en PDF grandes o malformados, ni la precisión del OCR — el pipeline PaddleOCR-via-rten se nombra pero no se somete a benchmark en el texto proporcionado. La división de licencias también es una advertencia estructural para cualquier equipo que planee depender de esto: la Community Edition en el repositorio público —CLI, servidor MCP, gateway REST, motor WASM y aplicación de escritorio— es Apache 2.0, pero SSO, RBAC, registros de auditoría y DLP quedan bloqueados detrás de una Enterprise Edition desarrollada por separado, lo que significa que los controles de gobernanza que probablemente necesitaría un despliegue regulado no forman parte de la compilación abierta.
El patrón replicable aquí es más acotado que "procesamiento de PDF zero-cloud": es un único núcleo en Rust compilado una vez y expuesto mediante bindings MCP, REST y WASM, de modo que una herramienta de documentos se comporta de forma idéntica ya sea que un agente la invoque por stdio o un usuario arrastre un archivo a una pestaña del navegador. Los equipos que construyen agentes basados en documentos a través de MCP deberían tratar la cifra de sub-5ms de ingesta como una afirmación acotada de un solo endpoint, no como un benchmark de todo el sistema, y deberían verificar si los controles de auditoría y acceso que necesitan están dentro de la Community Edition Apache 2.0 o bloqueados detrás de la licencia Enterprise separada antes de integrarlo en algo regulado.