This server provides local-first PDF manipulation tools that run entirely on your machine — no files are ever uploaded or transmitted over a network. It exposes the following capabilities:
pdf_merge: Combine two or more PDF files into a single document in a specified order.
pdf_split: Split a PDF by page ranges into multiple output files, or extract specific pages into a single new PDF.
pdf_rotate: Rotate all pages or a selected subset by any multiple of 90 degrees (e.g., 90°, 180°, -90°).
pdf_watermark: Stamp custom text on every page with configurable font size, opacity, color, and position.
pdf_bates: Add sequential Bates numbers to every page with options for prefix, starting number, zero-pad width, font size, color, and corner placement.
pdf_clean_metadata: Strip sensitive metadata including title, author, subject, keywords, creator, creation/modification dates, and the XMP metadata stream.
pdf_page_count: Return the total number of pages in a PDF file.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@quillpdf-mcp merge invoice1.pdf and invoice2.pdf into combined.pdf"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PDF operations for MCP. An MCP server and CLI for local PDF manipulation:
Merge, split, organize, delete pages
Rotate, crop
Watermark, Bates numbering, page numbers
Flatten forms, images → PDF
Metadata cleaning, page count
AES-256 protect / unlock
Built on pdf-lib. MIT licensed. stdio transport. No network calls — files never leave your machine.
npx -p quillpdf-mcp quillpdf --help # CLI
npx quillpdf-mcp --help # MCP server (your MCP client launches it over stdio)Or globally:
npm install -g quillpdf-mcp
quillpdf --helpRequires Node.js 18+.
Related MCP server: PDF Tools
quillpdf-mcp implements structural PDF transforms and AES-256 protect/unlock. It does not perform OCR, redaction, or compression — those are available in the browser version (quillpdf.com), where processing also stays client-side. They'll ship here only when they can run fully locally.
The MCP server speaks stdio and exposes one tool per operation.
Add to claude_desktop_config.json:
{
"mcpServers": {
"quillpdf": {
"command": "npx",
"args": ["-y", "quillpdf-mcp"]
}
}
}claude mcp add quillpdf -- npx -y quillpdf-mcpThen ask your assistant things like "merge invoice-1.pdf and invoice-2.pdf into combined.pdf" or "Bates-number discovery.pdf with prefix ABC starting at 1." The assistant supplies file paths on your machine; the server reads and writes them locally.
A ready-to-copy config lives in examples/mcp-config.json.
Tool | What it does |
| Merge 2+ PDFs into one, in order |
| Split by page ranges (one file per group) or extract specific pages into one file |
| Rotate pages by a multiple of 90° (all pages or a chosen subset) |
| Stamp text on every page (size / opacity / color / position) |
| Sequential Bates numbering (prefix, start, zero-pad, corner) |
| Strip info-dict fields + dates, and delete the XMP metadata stream |
| Count pages |
| Keep pages in the order you list — reorder, delete and duplicate in one step |
| Remove listed pages, keeping the rest in order |
| Stamp readable page numbers ( |
| Trim page margins by setting the CropBox — hides, does not remove (not redaction) |
| Paint filled form values onto the page so they can't be edited or read back as form data |
| Build a PDF from PNG/JPEG images, one per page |
| Encrypt with AES-256 so the document needs a password to open |
| Remove the password from a document you have the password for |
# Merge (order is preserved)
quillpdf merge a.pdf b.pdf c.pdf -o combined.pdf
# Split into one file per range group → out-1.pdf (pages 1-3), out-2.pdf (page 5)
quillpdf split in.pdf --ranges "1-3,5" -o out.pdf
# Extract specific pages into a single file (reordering/duplicates allowed)
quillpdf split in.pdf --pages "5,1,1" -o extract.pdf
# Rotate every page 90°, or just some pages
quillpdf rotate in.pdf --angle 90 -o rotated.pdf
quillpdf rotate in.pdf --angle 180 --pages "2,4" -o rotated.pdf
# Watermark
quillpdf watermark in.pdf --text "DRAFT" --opacity 0.15 --position center -o wm.pdf
# Bates numbering → PLT-000001, PLT-000002, …
quillpdf bates in.pdf --prefix "PLT-" --start 1 --pad 6 -o numbered.pdf
# Strip document metadata
quillpdf clean-metadata in.pdf -o clean.pdf
# Page count (prints a number)
quillpdf page-count in.pdfEvery command has --help.
Existing files are never silently replaced. If the -o path already
exists, the command stops with an error instead of clobbering it — add
--force (or force: true on the MCP tools) to replace it deliberately.
Local only. All PDF processing happens in-process via pdf-lib. The server communicates over stdio and never opens a network connection. (The MCP SDK bundles optional HTTP/SSE transports in node_modules, but this server only ever uses stdio, so none of that code runs.)
Password-protected PDFs are refused, not silently unlocked. Every operation except unlock stops with a clear message rather than stripping the password for you. unlock decrypts only with a password you supply — it does not recover, guess, or brute-force one.
Encryption engine. protect and unlock run QPDF (Apache-2.0) compiled to WebAssembly, in-process and offline like everything else. pdf-lib cannot encrypt at all, and the community forks that add it are unmaintained — encryption is the one operation where a subtle bug means a document you believe is locked isn't, so this uses the reference implementation instead.
AES-256 only. protect emits PDF 2.0 encryption revision 6. The 40-bit and 128-bit modes are deliberately not exposed: QPDF classes both as weak crypto, and shipping a "protected" file that isn't meaningfully protected is worse than shipping nothing.
Permission flags are a request, not a guarantee. --no-print / --no-copy / --no-modify set bits that a well-behaved reader honours; they are not enforced by the encryption. The password is the part that actually protects the file. (Extraction for accessibility stays permitted even with --no-copy, so screen readers keep working.)
Cropping is not redaction. crop sets the CropBox, so trimmed content is hidden but still present in the file and fully recoverable. Do not use it to remove sensitive material.
clean-metadata scope. It clears the title, author, subject, keywords, and creator fields plus the CreationDate/ModDate in the document information dictionary, and deletes the document-level XMP metadata stream — the copy Acrobat, Word, InDesign, and LibreOffice write, which is often the authoritative one. Note that pdf-lib rewrites the /Producer field with its own signature on save, so that one field is replaced rather than emptied. It does not scrub page-level annotations, embedded file attachments, or the text/image content of pages.
These need a Node image backend or an OCR engine and are planned for a later release — they are not in this package today:
compress (image re-encode) — needs an image codec such as sharp
pdf-to-image (render pages to PNG) — needs a rasterizer (pdfjs-dist + canvas)
redact (true rasterize-on-redact removal) — needs the same rasterizer
ocr (searchable-text layer) — needs tesseract.js
Each would roughly quadruple this package's dependency surface, which is the whole reason they're held back: the pitch here is a small, local, no-network tool. They'll ship only when they can run fully locally without giving that up.
Keep the server small, local, and easy to audit. Most "PDF API" tools answer document work with "upload it to us" — for legal discovery, medical records, or financials, the upload is the problem. This runs where you are; the bytes stay on your disk.
npm install
npm run build # tsc → dist/
npm test # builds, then runs the unit suite (node:test)The engine (src/core.ts) is pure: bytes in, bytes out, no I/O. The CLI (src/cli.ts) and MCP server (src/server.ts) are thin front-ends over it.
MIT © Purple Directive. See LICENSE.
Learn more at quillpdf.com.
Stamp sequential Bates numbers ({prefix}{zero-padded n}) on every page. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Color as #RRGGBB (default #000000) | |
| input | Yes | Path to the input PDF | |
| output | Yes | Path to write the numbered PDF | |
| prefix | No | Text before the number (default none) | |
| fontSize | No | Font size in points (default 10) | |
| padWidth | No | Zero-pad width (default 6) | |
| position | No | Corner (default bottom-right) | |
| startNumber | No | First number (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) provide basic behavioral traits. The description adds that processing is entirely local, which is useful but not extensive. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and 2 required, the description covers the core purpose and key behavior (local processing). It could mention output behavior but is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the format mention, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stamps sequential Bates numbers on every page, specifying the format {prefix}{zero-padded n}. It distinguishes from siblings by focusing on Bates numbering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that processing is local and the file never leaves the machine, providing clear context for privacy-sensitive use. It does not explicitly state when not to use, but the local processing hint is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip document metadata: clears title, author, subject, keywords, creator and the CreationDate/ModDate in the info dictionary, AND deletes the document-level XMP metadata stream (the copy Acrobat/Word/InDesign write). Note: pdf-lib rewrites /Producer with its own signature on save, so that one field is replaced rather than emptied. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Path to the input PDF | |
| output | Yes | Path to write the cleaned PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing that it deletes XMP metadata, notes that pdf-lib rewrites /Producer, and emphasizes that the operation runs locally. This provides essential behavioral insights not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and well-structured, with all sentences providing necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers all relevant aspects: what metadata is cleared, the /Producer behavior, and the local-only processing. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions. The tool description does not add any additional meaning beyond what is in the schema, meeting the baseline expectation for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it strips document metadata, listing specific fields (title, author, etc.) and XMP metadata, distinguishing it from sibling tools like pdf_merge or pdf_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use or avoid this tool versus alternatives, though the distinct purpose is implied by the sibling context. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge two or more PDF files into one, in the order given. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | Paths to the input PDFs, in merge order (2 or more) | |
| output | Yes | Path to write the merged PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral hints (readOnlyHint=false, etc.), but the description adds that execution is local and files are not sent, which is useful. However, it does not disclose handling of errors, overwrite behavior, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no wasted words. Efficiently communicates purpose and a key privacy trait.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and full parameter coverage, the description is mostly complete. It lacks mention of return value or success verification, but for a file-merging operation, the implied output is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds 'in the order given' which aligns with the inputs array but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges two or more PDF files into one in a given order, with a specific verb (merge) and resource (PDFs). It distinguishes from siblings like pdf_split and pdf_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to prefer pdf_merge over other PDF tools. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the number of pages in a PDF. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Path to the input PDF |
| Name | Required | Description |
|---|---|---|
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and idempotentHint; description adds that execution is local with no data sent externally, providing useful privacy context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple tool with one parameter and an output schema; could mention return type but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single parameter; description does not add extra meaning beyond 'Path to the input PDF'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Return the number of pages in a PDF'—specific verb and resource that distinguishes it from sibling tools like pdf_merge or pdf_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for local, private page counting but does not explicitly state when to use this tool over alternatives or exclude other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate pages by a multiple of 90 degrees. Omit pages to rotate every page. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| angle | Yes | Rotation in degrees; must be a multiple of 90 (e.g. 90, 180, -90) | |
| input | Yes | Path to the input PDF | |
| pages | No | 1-based pages to rotate (default: all) | |
| output | Yes | Path to write the rotated PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation but no idempotency or destructiveness. The description adds that the operation is local and the file is never sent elsewhere. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the core action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the main behavior and local execution. Lacks mention of return values, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that omitting 'pages' rotates all pages, which supplements the schema's default description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool rotates PDF pages by multiples of 90 degrees. It distinguishes from sibling tools like pdf_merge and pdf_split by specifying the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage hint: 'Omit `pages` to rotate every page.' Also mentions local execution, which implies privacy. Could be more explicit about alternatives, but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a PDF by 1-based page ranges (one output file per comma group, e.g. "1-3,5"), or extract specific pages into a single PDF (e.g. "1,3,5"). Provide exactly one of ranges or pages. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Path to the input PDF | |
| pages | No | 1-based pages for a single combined output, e.g. "1,3,5" | |
| output | Yes | Output path. In range mode with >1 group, files get -1, -2, … suffixes. | |
| ranges | No | 1-based ranges, one output per comma group, e.g. "1-3,5,7-9" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, not destructive), the description adds that execution is local and files are never sent anywhere, addressing privacy/security. It also describes output suffix behavior in range mode with multiple groups. This adds significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose, usage, and privacy. No redundant words. The key information is front-loaded: 'Split a PDF by 1-based page ranges... or extract specific pages'. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description covers input source, output paths, behavior for both modes, and the local execution guarantee. It is sufficiently complete for an agent to invoke correctly, including the mutual exclusivity of parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema covers all parameters with descriptions, the description adds critical usage semantics: that exactly one of pages/ranges must be provided, how outputs are named (suffixes in range mode), and the format of the strings. This goes beyond the schema's basic type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool splits PDF by page ranges or extracts specific pages, with concrete examples ("1-3,5", "1,3,5"). It distinguishes itself from sibling tools like pdf_merge (which combines PDFs) and pdf_page_count (which only counts pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Provide exactly one of `ranges` or `pages`', giving clear usage direction. It explains the difference between range mode (one output per group) and pages mode (single output). However, it does not explicitly mention when not to use this tool (e.g., for simple page extraction without ranges) beyond the constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stamp a text watermark on every page. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Watermark text | |
| color | No | Color as #RRGGBB (default #808080) | |
| input | Yes | Path to the input PDF | |
| output | Yes | Path to write the watermarked PDF | |
| opacity | No | Opacity 0-1 (default 0.15) | |
| fontSize | No | Font size in points (default 48) | |
| position | No | Placement (default center) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds privacy guarantee (runs locally, never sends file) beyond annotations. Also clarifies it stamps every page. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with core action, followed by privacy note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 7-param tool with full schema coverage, but lacks details on output behavior, error handling, or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra parameter meaning beyond the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stamps a text watermark on every page, using specific verbs and resource. It distinguishes from sibling tools like pdf_bates (Bates numbering) and pdf_merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned. Only implicit context from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct and well-defined purpose (bates numbering, metadata cleaning, merging, page count, rotating, splitting, watermarking) with no overlap in functionality.
All tool names follow a consistent 'pdf_verb_noun' pattern (e.g., pdf_merge, pdf_rotate, pdf_watermark), making them predictable and easy to understand.
With 7 tools, the set is well-scoped for a PDF utility server, covering essential operations without being overwhelming or sparse.
The tool set covers common PDF manipulation tasks (merge, split, rotate, watermark, metadata, page count, bates numbering), but could benefit from additional features like encryption or text extraction.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Privacy-first PDF tools over MCP: merge, split, rotate, delete, compress, protect, inspect.
Sign, fill, merge and split PDFs entirely in your browser - files never leave your device.
84+ free local-first tools: image, PDF, docs, dev utils. Wasm, zero upload, x402 API.
125+ browser tools for PDF, Image, Video, Audio, AI, Scanner. Files never leave your device.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PurpleDirective/quillpdf-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
