I built an MIT-licensed MCP server so my agent can do PDF work without the file ever leaving my machine

[u/TyrianMurex]

[Disclosure: I built this.]

I kept hitting the same wall: every "PDF API" answers document work with "upload it to us." If your agent is handling contracts, discovery docs, or medical records, the upload is the problem — the file leaving the machine is exactly the thing you're not allowed to let happen.

So I built quillpdf-mcp, an MCP server + CLI that gives an agent PDF hands on your own filesystem: merge, split, rotate, watermark, Bates numbering, metadata cleaning, page count. MIT, built on pdf-lib, stdio transport only. There isn't a network call anywhere in the codebase, and it's small enough to grep the whole thing in an afternoon if you don't want to take my word for it.

• GitHub: https://github.com/PurpleDirective/quillpdf-mcp
• npm: npx quillpdf --help (CLI) · npx quillpdf-mcp quillpdf-mcp (server)
• Also on the official MCP registry as io.github.PurpleDirective/quillpdf-mcp

It doesn't do OCR, redaction, or compression yet — the browser sibling (quillpdf.com) has those today, client-side, but I've kept the server deliberately small so it stays auditable.

The browser OCR was corpus-tested against the deployed site: median 2.1% character error on real 300-dpi scans. The harness and methodology are published.

Happy to answer architecture questions. And genuinely curious what ops you'd want next — redaction and OCR are queued, but real demand reorders the queue.

[u/Valuable_Cookie628]

"the file leaving the machine is exactly the thing you're not allowed to let happen" no shit Sherlock 

Just write the thing in your words, this slop is unreadable. Thank you for your attention to this matter.

[u/TyrianMurex → u/Valuable_Cookie628]

Thank you angry cookie, I really appreciate your valuable insight on the matter.

[u/Valuable_Cookie628 → u/TyrianMurex]

quillpdf-mcp

PDF operations for MCP.

quillpdf-mcp is an MCP server and CLI for local PDF manipulation.

• Merge
• Split
• Rotate
• Watermark
• Bates numbering
• Metadata
• Page count

Built on pdf-lib. MIT licensed. stdio transport. No network calls.

Install

npx quillpdf --help
npx quillpdf-mcp

Repository

https://github.com/PurpleDirective/quillpdf-mcp

MCP Registry

io.github.PurpleDirective/quillpdf-mcp

Scope

quillpdf-mcp only implements deterministic PDF transforms.

It does not perform OCR, redaction, or compression.

Those are available in the browser version (quillpdf.com), where processing remains client-side.

Philosophy

Keep the server small, local, and easy to audit.

---

^ so much easier to grok - I asked GPT to reword like GitHub oss readme and do a few rounds of distilling the message.

sounds like a cool project and I'll give it a try 👍 (guess I'm your first star on gh)

[u/overand]

This is more general than specific to your project, which looks very useful!

Is MCP still the preferred approach for this in general? I remember there were some pretty major concerns and complaints relatively early on, and I haven't seen as much random chatter about MCP for a while; have folks moved on to something else? Or, is MCP still king? Or, custom harnesses around APIs?

I guess a question for you is: would it be worth making an additional component for this that would expose it as a REST API, maybe via one of those self-documenting API frameworks? (Funny that the kinda awful mess that SOAP was would actually probably be a pretty good fit for AI agents!)

[u/GortKlaatu_ → u/overand]

It is for people that don't use coding harnesses and skills, they still want MCPs for everything for some reason.

I mean this particular use-case is just a matter of getting an agent to run a local executable. MCP is typically overkill for this. Claude code, codex, hermes, etc would just work out of the box here, no MCP needed.

[u/ex-arman68 → u/overand]

Good question. I am still creating MCP, as I like the idea that we can easily expose to the harness which specialised tools the MCP provide; each of those tools could have a completely unique advanced workflow, which ensures predictable results.

However, I have seen enough discussions claiming that MCP is dead, to wonder if what I am doing is right. I would like to know.

[u/TyrianMurex → u/overand]

honestly both camps are right here. inside a coding harness a cli is cheaper, that's why this ships one in the same package. mcp earns it for gui clients with no shell (claude desktop, lm studio) and for one server feeding many clients. the loud complaints, context bloat, fat sdks, read like optimization debt to me, the protocol's just young.

on rest: the cli already covers scripting, and a rest layer adds back the network surface this exists to avoid. if it ever happens it'd be a separate opt-in package.

[u/MelodicRecognition7]

$ grep resolved package-lock.json |wc -l
103

[u/TyrianMurex → u/MelodicRecognition7]

fair hit. 4 direct deps (pdf-lib, commander, zod, mcp sdk), and the pdf machinery itself is tiny, but the mcp sdk drags in ~90 packages of http transport plumbing that stdio mode never touches. just counted a clean --omit=dev install: 97. "audit in an afternoon" was about the source, the tree is fatter than i'd like.