EP echo-pdf docs
Docs only, not a service

Local-first PDF context for agents.

echo-pdf turns local PDFs into reusable package APIs, CLI outputs, and workspace artifacts. This site explains the product boundary and local workflows. It does not expose hosted PDF processing.

Primary surfaces

  • @echofiles/echo-pdf npm package
  • echo-pdf local CLI
  • .echo-pdf-workspace/ inspectable artifacts
  • static docs site for install and contracts

Non-goals in this phase

  • hosted SaaS or multi-tenant platform work
  • treating MCP as the main entrypoint
  • turning the site into an online playground
  • datasheet / EDA or other domain-specific logic
6

core document primitives, mirrored by the local CLI and package API.

3

main product surfaces: package, CLI, workspace artifacts.

0

hosted promises. This site documents a local product, not a remote service.

Install and run locally

npm i -g @echofiles/echo-pdf

echo-pdf document ./sample.pdf
echo-pdf structure ./sample.pdf
echo-pdf semantic ./sample.pdf
echo-pdf page ./sample.pdf --page 1
echo-pdf render ./sample.pdf --page 1
echo-pdf ocr ./sample.pdf --page 1 --model gpt-4.1-mini

What the local run gives you

  • stable page index via structure.json
  • optional semantic layer via semantic-structure.json
  • page JSON, render PNG, and OCR JSON artifacts under one workspace root
  • cache reuse keyed by source snapshot and strategy metadata

API

Read the six local-first primitives and how they map to the artifact model.

CLI

Use the same six primitives from the command line, with a clear source-checkout workflow.

What this site is for

Explain install, contracts, local-first workflows, and the shape of the public product.

What this site is not

An online PDF processor, hosted dashboard, account surface, or remote API playground.

How downstream products should read it

Use it as the docs layer for a local component. Build product-specific logic outside echo-pdf.

Compatibility surfaces are secondary.

Worker and MCP surfaces may still exist in the repo for compatibility, but they are not the main adoption path in this phase. The homepage, concepts, API, and CLI sections intentionally keep the center of gravity on local package + CLI + artifacts.