Paperboy

Official

Overview Schema Source Related Servers Discussions Admin

sanitize_pdf

DestructiveIdempotent

Remove hidden PDF data—metadata, scripts, attachments, comments, thumbnails, and prior versions—then assign a new random ID while preserving links, bookmarks, and form fields.

Instructions

Write a copy without hidden data: metadata (incl. comment authors and camera data in images), scripts and risky actions, and attachments (comments too if remove_comments=true), plus application data, thumbnails, earlier saved versions and unused resources; gives it a new random ID. Links, bookmarks, form fields and accessibility structure are kept. Not removed: hidden layers, text hidden by colour or position, form field values, and the second half of an encrypted copy's ID (set by the PDF library from the time). removed is measured on the result; if anything asked for can't be removed, nothing is written. Needs the owner password if the PDF forbids changes, or forbids changing comments and has any. Signed PDFs are refused.

Any password argument can be "ask": the user then types it on a local page, so it never passes through the chat.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_path": "<input_path>"
    },
    "name": "sanitize_pdf"
  }
}

Input Schema

Name	Required	Description	Default
`password`	No
`overwrite`	No
`input_path`	Yes
`output_path`	No
`remove_scripts`	No
`remove_comments`	No
`remove_metadata`	No
`remove_attachments`	No

Output Schema

Name	Required	Description	Default
`output`	Yes
`removed`	Yes
`document_id_reset`	Yes
`password_protected`	Yes
`user_password_changed`	Yes
`permissions_restricted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses the exact removal set, the explicit non-removal list (hidden layers, colour/position-hidden text, form field values), all-or-nothing atomicity ('if anything asked for can't be removed, nothing is written'), and new random ID assignment. The only gap is that the annotations also declare idempotentHint=true, and the 'new random ID' phrasing is not reconciled with repeat-run behavior, though this is not a true contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the removal list, then the exceptions and prerequisites; nearly every clause carries actionable information. The trailing password-'ask' paragraph is valuable but bolted on after the atomicity statement, slightly disrupting the flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter destructive mutation with an output schema, this is close to full coverage: what is destroyed, what survives, failure/atomicity behavior, password and signed-PDF constraints, and the 'ask' safety flow are all stated. Only overwrite/output_path behavior is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry the load, and it does for most flags: the removal categories map directly to remove_scripts/remove_metadata/remove_attachments, and the 'comments too if remove_comments=true' clause explains that parameter's off-by-default behavior. Password semantics are also clarified via the 'ask' convention. overwrite and output_path are never explained, leaving two parameters undocumented everywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Write a copy without hidden data') and enumerates exactly what is stripped versus kept, so an agent can tell this apart from redact_pdf or extract_attachments without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives useful conditional context (needs owner password when the PDF forbids changes, signed PDFs are refused, passwords may be 'ask'), but never states when to choose this over siblings like redact_pdf or flatten_pdf, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.