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 "Deploy 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: VaultPDF MCP
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) | |
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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 already declare the write/idempotency/destructive profile (readOnly=false, idempotent=false, destructive=false). The description adds genuinely new context: the operation runs entirely on this machine and the file is read and written locally and never transmitted, which is real behavioral information not derivable from annotations or schema.
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, zero filler, with the core action front-loaded and the privacy guarantee as a supporting clause. 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?
With 100% schema coverage and no output schema, the description needn't restate parameters or return values. It covers purpose and the local-processing guarantee well; the only real gap is sibling disambiguation against pdf_page_numbers.
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 the baseline is 3. The description earns a bump by explaining the composed format "{prefix}{zero-padded n}", which conveys how the prefix and padWidth parameters interact in the stamped output — a relationship the schema states only in isolation.
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 gives a specific verb and resource ("Stamp sequential Bates numbers") and scope ("on every page"). It's clear what the tool does, but it never distinguishes itself from the close sibling pdf_page_numbers, so an agent gets no help telling the two apart.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives like pdf_page_numbers or pdf_watermark. The agent is left to infer that this is the legal-numbering variant purely from the name.
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 |
|---|---|---|---|
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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?
Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing the /Producer exception, the exact scope of destruction including the XMP stream, and that processing is entirely local with no network transmission. The clobber-safety default is reinforced in the schema but the local-only guarantee is extra, privacy-relevant context.
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?
Front-loaded with the action and its scope, followed by the caveat and the privacy note; each of the three sentences carries information an agent cannot get from annotations or schema. No filler.
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 file-transforming tool with no output schema, the description covers what is removed, the one field that isn't fully emptied, clobber protection, and data locality — everything needed to call it correctly and predict the result.
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 input/output/force are fully documented structurally; the force-clobber semantics are already in the schema. The description adds the Producer rewrite caveat, which is behavioral rather than parameter-level, so baseline 3 applies.
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?
States a specific verb (strip) and resource (document metadata), then enumerates the exact fields cleared (title, author, subject, keywords, creator, CreationDate/ModDate) plus the XMP stream. This is unmistakably distinct from every sibling (merge/split/rotate/protect/etc.), none of which touch metadata.
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 intended scenario (removing identifying metadata before sharing) is only implied by the enumeration of authorship fields; there is no explicit when-to-use statement, no exclusions, and no named alternative among the 14 siblings. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trim the visible area of each page by the given margins, in points (72 = 1 inch). This sets the CropBox, so the trimmed content is HIDDEN, not removed — it stays in the file and anyone can restore it. Cropping is not redaction. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Points to trim from the top (default: 0) | |
| left | No | Points to trim from the left (default: 0) | |
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| right | No | Points to trim from the right (default: 0) | |
| bottom | No | Points to trim from the bottom (default: 0) | |
| output | Yes | Path to write the cropped PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the core behavioral hazard: the crop sets CropBox so trimmed content is HIDDEN, remains in the file, and can be restored. It also discloses local-only processing ('never sent anywhere'), which is meaningful privacy context that no annotation conveys.
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?
Three short sentences, each earning its place: the mechanics, the restorability caveat, and the local-processing note. The core operation is front-loaded and the important warning follows immediately.
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?
There is no output schema, so the description carries the burden, and it adequately covers what happens to the input file and the crop semantics. It does not mention the overwrite behavior governed by 'force' or error/interaction with an existing output file, which the schema only partially covers.
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 the baseline is 3, but the description adds the point-to-inch conversion (72 = 1 inch) that explains how to interpret the numeric margin values in practice. The per-side vs. aggregate margin semantics are still left to the schema's per-parameter 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?
States a specific verb and resource ('Trim the visible area of each page by the given margins') and immediately pins down the unit convention ('in points, 72 = 1 inch'). This is clearly distinguishable from sibling operations like pdf_rotate, pdf_watermark, 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?
Gives clear context for use and an explicit exclusion boundary: 'Cropping is not redaction,' which steers an agent away from using this when the goal is permanent content removal. It stops short of naming a specific alternative tool or redaction workflow to use instead, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the listed pages, keeping everything else in its current order. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| pages | Yes | Pages to DELETE, 1-based. e.g. "2,5-7" | |
| output | Yes | Path to write the result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely new context: the file is read and written locally and never transmitted. It does not address overwrite/force behavior or what happens with out-of-range pages, but it materially enriches the safety picture beyond the 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 filler, with the core operation front-loaded and the local-processing reassurance placed second. Every clause 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?
No output schema exists, so the description needn't explain return values, and all four parameters are covered by the schema. The local-only guarantee rounds out the picture; only edge cases (invalid page numbers, overwrite resistance) are left undocumented, which is minor for a straightforward file transform.
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% — every parameter including the 1-based page-range syntax ('2,5-7') and the force overwrite flag is already documented in the schema. The description adds no parameter-level detail, so baseline 3 applies.
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?
States a specific verb and resource ('Remove the listed pages') and adds the ordering guarantee, which lets an agent distinguish it from pdf_split or pdf_organize. It stops short of explicitly naming a sibling alternative, but the operation is unambiguous.
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?
Usage is implied by the wording but there is no explicit when-to-use guidance or named alternative (e.g., pdf_split for extracting pages, pdf_organize for reordering). An agent must infer that this is the page-removal tool from name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paint filled form values onto the page as static content. Afterwards the answers are still readable but can no longer be edited, cleared, or extracted as form data. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| output | Yes | Path to write the flattened PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says answers 'can no longer be edited, cleared, or extracted as form data,' which is a destructive change to form data. The annotations declare destructiveHint=false, creating a direct contradiction rather than useful additional context.
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?
Three concise, front-loaded sentences with zero waste: it states the operation, then the consequence, then local execution. Each 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?
For a 3-param tool with full schema coverage and no output schema, the description covers operation effect, irreversibility, and local execution. It omits force/output handling details, but those are schema-documented, so it is close to 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 coverage is 100%, with all three parameters including force documented in the schema. The description adds no parameter syntax or meaning beyond what the schema already provides, so the baseline 3 applies.
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?
States a specific verb ('Paint filled form values onto the page as static content') and resource (PDF form), plus the end state, clearly distinguishing this flattening operation from sibling PDF utilities.
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?
Implies use when you want to freeze filled form values, but gives no explicit when-not guidance or alternatives (e.g., versus pdf_protect or pdf_clean_metadata). Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a PDF from PNG and/or JPEG images, one image per page, in the order given. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| inputs | Yes | Paths to the images, in page order | |
| output | Yes | Path to write the PDF | |
| pageSize | No | "fit" sizes each page to its image; a4/letter centres it on a fixed page (default: a4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=false and non-destructive/idempotent flags, the description adds a genuinely useful trait beyond structured data: it runs entirely locally and never transmits files. It does not, however, explain what happens when the output path already exists (the 'force' contract) or how failures surface, so it stops short of full behavioral coverage.
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 and ordering rule, second sentence carrying the privacy guarantee. No filler or 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?
For a straightforward creation tool with full schema coverage, annotations for the safety profile, and no output schema, the description covers what the agent needs. Minor gap: it does not mention overwrite behavior or the default page size, though the latter is caught by the schema.
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 all four parameters (inputs, output, pageSize enum, force) are already documented in the schema. The description only restates the ordering semantics of 'inputs' that the schema already conveys, adding no new syntax or format detail. Baseline 3 applies.
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?
Names a specific verb ('Build a PDF') and resource ('from PNG and/or JPEG images'), plus the exact layout contract ('one image per page, in the order given'). This is clearly distinguishable from every sibling, all of which manipulate existing PDFs rather than create one from images.
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?
Usage is implied by the input types (you have images, you want a PDF), but the description never states when to prefer this over alternatives such as pdf_merge (combining existing PDFs) or when not to use it. No prerequisites or exclusions are given.
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 |
|---|---|---|---|
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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 declare write behavior (readOnlyHint=false, non-idempotent), and the description adds genuinely new context: processing is local-only and files are never transmitted. That privacy guarantee is not available in schema or annotations. It does not, however, discuss side effects like overwrite handling beyond what the schema states.
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 the core action and scope; the local-processing note earns its place as non-obvious behavior. No filler.
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 3-parameter tool with no output schema and full schema coverage, the essentials are covered: what it does, ordering, and a local-only security guarantee. It could mention the existing-file overwrite behavior, but that is adequately handled by the schema's force parameter.
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 all three parameters (inputs, output, force) are already documented in the schema. The description only reinforces the merge-order semantics of inputs, adding little beyond the structured fields. Baseline 3 applies.
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?
States a specific verb and resource ('Merge two or more PDF files into one') plus the ordering constraint ('in the order given'), which cleanly separates it from siblings like pdf_split, pdf_organize, and pdf_from_images.
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 implies its use case (combining multiple PDFs) but never states when to prefer it over alternatives such as pdf_organize or pdf_split, nor any prerequisites or exclusions. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild a PDF keeping only the pages you list, in the order you list them. Reordering, deleting and duplicating are all the same operation: a page you omit is dropped, a page you move is reordered, and a page listed twice is duplicated. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| pages | Yes | Pages to KEEP, in the order wanted, 1-based. e.g. "3,1,5-8". Order matters; repeat a number to duplicate that page. | |
| output | Yes | Path to write the organized PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds a genuinely new behavioral trait — the file is processed entirely locally and never transmitted — which is exactly the kind of context annotations cannot express. It stops short of disclosing what happens when output already exists (only the 'force' param hints at this) or whether input can equal output.
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?
Three short sentences, front-loaded with the core operation, then the unifying insight about delete/reorder/duplicate, then the local-execution note. Every sentence carries distinct information and nothing is padded.
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 no output schema, the description carries the return-value burden, and for a file-writing tool it adequately conveys that the result is a rebuilt PDF written to a path. Combined with 100% schema coverage and existing annotations, an agent has enough to call it correctly; the only minor gap is overwrite/force behavior, which is left to the schema.
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 all four parameters (input, pages, output, force) are already documented with format and 1-based indexing. The description restates the pages semantics (order matters, repeat to duplicate) but adds no syntax or constraint beyond the schema, so the baseline 3 applies.
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?
States a concrete verb+resource ('Rebuild a PDF') and immediately defines scope: which pages survive and in what order. It also makes explicit that reordering, deleting and duplicating are all this one operation, which implicitly separates it from siblings like pdf_delete_pages and pdf_rotate without the agent needing to open either schema.
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?
Gives clear operative guidance on what the tool does in each case (omit = drop, move = reorder, list twice = duplicate), which tells an agent when this tool subsumes other operations. However, it never names an alternative sibling (e.g. pdf_delete_pages, pdf_split) or states when NOT to use this, so routing is inferred rather than explicit.
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.
Stamp readable page numbers on each page. Distinct from Bates numbering: these are a reading aid (centred, optional "of N" total, skippable cover), not a legal evidence-control device. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Hex colour #RRGGBB (default: #000000) | |
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| format | No | "3" | "3 of 12" | "Page 3 of 12" (default: plain) | |
| output | Yes | Path to write the numbered PDF | |
| fontSize | No | Point size (default: 10) | |
| position | No | Where to place the number (default: bottom-center) | |
| skipFirst | No | Leave page 1 unstamped, e.g. a cover. Later pages keep their true position (page 2 still reads "2 of 12"). | |
| startNumber | No | Number for the first page (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly=false, idempotent=false, destructive=false, but the description adds meaningful context beyond them: the operation is local-only and the file is never transmitted. It also notes cover skipping, which affects output. It does not explain overwrite semantics or why it is non-idempotent, leaving minor gaps.
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?
Three tight sentences, each earning its place: what it does, how it differs from the closest sibling, and the local-processing guarantee. The differentiator is front-loaded after the core action.
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 nine-parameter mutation tool with a fully documented schema and no output schema, the description covers purpose, sibling disambiguation, and privacy. The only notable omission is output/overwrite behavior relative to the input file, though the force parameter partially addresses this.
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 all nine parameters are documented in the schema itself. The description's mention of 'centred, optional of N total, skippable cover' loosely maps to position/format/skipFirst but adds no syntax or defaults beyond the schema, so it sits at the baseline.
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?
States a specific verb+resource (stamp page numbers on each page) and explicitly distinguishes itself from the sibling pdf_bates by explaining this is a reading aid, not legal evidence control. An agent can route between the two without opening either schema.
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 Bates contrast implies when to use this tool versus the alternative, and the 'reading aid' framing clarifies intent. However, it does not state explicit preconditions (e.g., that input must be a valid PDF, or when numbering is inappropriate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encrypt a PDF with AES-256 so it cannot be opened without the password. Only AES-256 is offered — 40-bit and 128-bit are classed as weak crypto. The password is used locally and never transmitted; it also cannot be recovered, so it must be stored somewhere safe. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the input PDF | |
| noCopy | No | Disallow text/graphic extraction (accessibility extraction stays permitted) | |
| output | Yes | Path to write the protected PDF | |
| noPrint | No | Disallow printing (enforced by the reader, not the encryption) | |
| noModify | No | Disallow editing and form filling | |
| password | Yes | Password required to open the document |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing that the password is used locally and never transmitted, that it is unrecoverable and must be stored safely, and that the file is read and written entirely on this machine. This is exactly the behavioral context an agent needs for a security-sensitive mutation.
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?
Front-loaded with the core action and its consequence, and each sentence carries weight. Slight redundancy between 'never transmitted' and 'never sent anywhere' costs it the top score.
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 7 params fully documented in the schema and annotations covering the mutation profile, the description supplies the missing security/locality context and needs no return-value documentation. It could say a bit more about overwrite behavior or the durability of the restriction flags, but nothing essential 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?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning for the critical password parameter (used locally, never transmitted, unrecoverable) and pins the encryption strength. It does not clarify the interaction of the restriction flags (noCopy/noPrint/noModify) with the encryption, which the schema already documents individually.
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?
States a specific verb (encrypt / password-protect) and resource (PDF) plus the concrete outcome: the file cannot be opened without the password. An agent can immediately distinguish it from the inverse sibling pdf_unlock.
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?
Usage is implied by the stated outcome, and it usefully notes that only AES-256 is offered while 40/128-bit are considered weak, which guides the choice of algorithm. However, it never explicitly says when to pick this over alternatives or names the counterpart tool (pdf_unlock) for removing protection.
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) | |
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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 declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds genuinely new context: processing is entirely local with no remote transmission. It does not detail return behavior or the clobber/force semantics, but it goes beyond the annotations where it matters most for trust.
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?
Three short sentences, each earning its place: the operation and its constraint are front-loaded, followed by the default-page rule and the local-processing guarantee. No filler.
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?
No output schema exists, so the description could say more about what is returned after the write, but for a straightforward local file transform the essentials (constraint, default scope, privacy) are covered and the annotations carry the safety profile.
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 every parameter (angle, force, input, output, pages) is already documented in the schema. The description only restates the pages default and the 90-degree constraint, adding no syntax or format detail 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?
States a specific verb and resource ("Rotate pages") plus the operative constraint ("by a multiple of 90 degrees"). Rotation is unique among the sibling set, so no sibling can be confused with it, and an agent knows exactly what the tool produces.
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?
"Omit `pages` to rotate every page" gives a usage rule for one parameter, but there is no when-to-use/when-not framing and no mention of alternatives (e.g. pdf_organize) for reordering vs. rotating. Usage is implied rather than guided.
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 |
|---|---|---|---|
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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?
Annotations already declare non-read-only, idempotent, non-destructive behavior, so the description only needs to add context. It does: it discloses that processing runs entirely on the local machine and the file is never transmitted, which is meaningful privacy information not present in the annotations or schema. It does not cover error behavior for invalid ranges.
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 dense sentences, front-loaded with the core split/extract distinction, followed by the mutual-exclusivity constraint and the local-processing guarantee. Every clause carries information; no filler.
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 5-parameter local file tool with no output schema, the description covers both operation modes, parameter exclusivity, output naming, and the privacy guarantee. Remaining gaps are minor: no mention of behavior on invalid/out-of-range pages or overlap with `force`, though the latter is documented in the schema.
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 the baseline is 3, but the description adds real value the schema lacks: it states that exactly one of `ranges` or `pages` must be provided (the schema marks both optional with no mutual-exclusion constraint) and clarifies the output-file-per-group semantics, complementing the suffix note in 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 names a specific verb and resource ('Split a PDF', 'extract specific pages into a single PDF') and clearly distinguishes its own two modes. It does not, however, differentiate itself from close siblings like pdf_delete_pages or pdf_organize, which an agent may also consider for page-level manipulation.
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?
It gives an explicit selection rule for the two modes: use `ranges` for one output per comma group and `pages` for a single combined output, with concrete examples. What's missing is guidance relative to sibling tools (e.g., when to use split vs. delete_pages or organize).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decrypt a password-protected PDF you know the password for, so it opens without prompting. This does NOT recover, guess, or brute-force a forgotten password. Runs entirely on this machine — the file is read and written locally and never sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Replace the output file if it already exists | |
| input | Yes | Path to the protected PDF | |
| output | Yes | Path to write the unlocked PDF | |
| password | Yes | The document's current password |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond them: it emphasizes local-only processing ('the file is read and written locally and never sent anywhere') and the known-password precondition. It omits what happens with the force/overwrite path, though the schema documents that.
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?
Three short sentences, front-loaded with the core action and outcome, followed by the key exclusion and privacy note. Every sentence carries distinct value with no filler.
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?
No output schema exists, so the description must carry return semantics; it communicates the effect (a decrypted PDF written to the output path) implicitly but does not state the return value or success/error shape. Combined with the strong privacy and password-context notes, it is nearly complete for a simple file-transform tool.
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 all four parameters (input, output, password, force) are already documented in the schema. The description adds no additional syntax, format, or path semantics beyond that, so the baseline 3 applies.
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?
States a specific verb (decrypt) and resource (password-protected PDF), plus the outcome ('opens without prompting'). It is clearly distinguished from the inverse sibling pdf_protect.
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?
Explicitly rules out the main misuse case: it does NOT recover, guess, or brute-force forgotten passwords, and it requires knowing the password. It gives clear conditions for use but does not name an alternative tool (e.g., pdf_protect) for the opposite task.
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) | |
| force | No | Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered) | |
| 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?
Annotations declare readOnly=false, idempotent=false, destructive=false, and the description meaningfully adds that processing is local — the file is read and written on this machine and never sent anywhere. That privacy/execution-model detail is genuine context beyond the annotations, though it says nothing about overwrite behavior (left to the force param).
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 tight sentences with the operation stated first and the execution/privacy note second. No filler or 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?
For an 8-parameter local file tool with fully documented schema and no output schema, the description covers purpose and the non-obvious privacy behavior. Overwrite semantics are handled by the schema's force description, so remaining gaps are minor.
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 eight parameters including force, opacity, fontSize, and the position enum. The description adds no parameter detail, so the baseline 3 applies.
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 states a specific verb and resource — 'Stamp a text watermark on every page' — and the 'every page' scope tells the agent the extent of the operation. It is clearly a watermarking tool distinct in intent from sibling text-overlay tools like pdf_bates or pdf_page_numbers, but it never names or contrasts a sibling explicitly.
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?
There is no when-to-use guidance, no prerequisites, and no alternatives named. The privacy sentence ('Runs entirely on this machine') is context about processing location, not guidance on when to select this tool over pdf_bates or pdf_page_numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0pdf_bates1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}pdf_clean_metadata1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}pdf_croppdf_delete_pagespdf_flattenpdf_from_imagespdf_merge1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}pdf_organizepdf_page_numberspdf_protectpdf_rotate1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}pdf_split1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}pdf_unlockpdf_watermark1 field changedInput schema / properties / forceAdded value: +{
+ "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
+ "type": "boolean"
+}v0.1.0pdf_batespdf_clean_metadatapdf_mergepdf_page_countpdf_rotatepdf_splitpdf_watermarkScored across 15 tools
Most tools have distinct purposes, but pdf_split, pdf_organize, and pdf_delete_pages overlap around selecting/reordering pages, and pdf_watermark, pdf_bates, and pdf_page_numbers all stamp content. Descriptions explicitly clarify each, so misselection risk is moderate rather than severe.
All tool names use the pdf_ prefix and snake_case consistently. However, they mix verb-first names (pdf_merge, pdf_rotate) with noun phrases (pdf_page_count, pdf_bates, pdf_watermark), so the pattern is not a strict verb_noun convention.
15 tools is well within the ideal range for a PDF manipulation suite. Each tool covers a distinct common operation without obvious redundancy or bloat.
The set covers create, merge, split, rotate, watermark, encrypt/decrypt, metadata cleanup, page numbering, crop, delete, organize, flatten, and count. Notable gaps remain for redaction (explicitly distinguished from crop), text/image extraction, compression, and form filling, which will limit some agent workflows.
Split, merge and compress PDF files locally - private by design, no uploads.
Privacy-first PDF tools over MCP: merge, split, rotate, delete, compress, protect, inspect.
Merge, split, extract, rotate, reorder and stamp PDF pages from your AI chat, all offline.
Merge, split, extract, rotate, reorder and stamp PDF pages from your AI chat, all offline.
