Paperboy

Official

Overview Schema Source Related Servers Discussions Admin

encrypt_pdf

DestructiveIdempotent

Add a password to a PDF to restrict opening and control printing, copying, or editing, with optional AES-256 encryption and support for already-encrypted files.

Instructions

Add a password to a PDF.

user_password opens the file; owner_password (defaults to it) controls permissions. algorithm: AES-256 (default), AES-128, RC4-128, RC4-40. allow_print/copy/modify set viewer-enforced restrictions. Use current_password if the input is already encrypted; re-encrypting a PDF that restricts anything needs its owner password (new permissions would lift the old ones). 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>",
      "user_password": "<user_password>"
    },
    "name": "encrypt_pdf"
  }
}

Input Schema

Name	Required	Default
`algorithm`	No	AES-256
`overwrite`	No
`allow_copy`	No
`input_path`	Yes
`allow_print`	No
`output_path`	No
`allow_modify`	No
`user_password`	Yes
`owner_password`	No
`current_password`	No

Output Schema

Name	Required	Description	Default
`pages`	Yes
`output`	Yes
`algorithm`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Nov 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "algorithm": {
+      "title": "Algorithm",
+      "type": "string"
+    },
+    "output": {
+      "title": "Output",
+      "type": "string"
+    },
+    "pages": {
+      "title": "Pages",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "output",
+    "algorithm",
+    "pages"
+  ],
+  "title": "EncryptResult",
+  "type": "object"
+}

First observedv0.1.0Oct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already carry the safety profile (destructiveHint=true, idempotentHint=true), and the description adds genuinely new behavioral facts: owner_password falls back to user_password, viewer-enforced vs owner-enforced restriction semantics, the rule that new permissions would lift old ones on re-encryption, and hard refusal of signed PDFs. The "ask" convention for password arguments — keeping secrets out of the chat transcript — is exactly the kind of security-relevant behavior an agent cannot get from structured fields.

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?

Purpose is front-loaded in one line, followed by parameter-focused sentences and a closing security note; there is essentially no filler. It is dense to the point of being list-like, and the parenthetical about owner passwords on re-encryption is slightly convoluted, but every sentence earns its place.

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 a 10-parameter destructive tool, the definition covers password roles, cipher choice, permission flags, pre-existing encryption, and refusal conditions, and an output schema exists so return values need no explanation. The only substantive omission is output/overwrite behavior, which is minor relative to the ground covered.

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 has to carry all parameter meaning, and it does for eight of ten: user_password, owner_password, current_password, algorithm (with the enumerated cipher choices not present in the schema), the three allow_* flags, and the magic "ask" value. The gaps are input_path, output_path, and overwrite — including what happens when both paths default to null on a destructive operation — which leaves a real ambiguity unresolved.

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?

"Add a password to a PDF" is a specific verb+resource that an agent can immediately distinguish from siblings like decrypt_pdf or check_pdf. The first sentence does the whole job of establishing scope before any parameter detail appears.

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

Usage Guidelines4/5

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

It gives concrete conditional guidance: use current_password when the input is already encrypted, supply the owner password when re-encrypting a PDF with restrictions, and expect refusal on signed PDFs. What it lacks is an explicit statement of alternatives (e.g., decrypt_pdf for removing protection), so an agent must infer the counterpart operation.

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