Encrypt PDF files with AES-256 using a user password, owner password, or permission limits to restrict opening, printing, and copying.
Encrypt with AES-256: a password to open and/or restricted permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| output | Yes | ||
| overwrite | No | ||
| allow_copying | No | ||
| user_password | No | ||
| allow_printing | No | ||
| owner_password | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish write (readOnlyHint=false), non-destructive, and closed-world behavior, so the safety profile is partly covered. The description usefully discloses that a password controls opening and/or permission restrictions, but says nothing about writing a new output file, overwrite semantics, or irreversibility, leaving notable behavioral gaps for an encryption tool.
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?
A single front-loaded sentence with no filler, which is structurally clean. However, its brevity comes at the cost of omitting necessary detail rather than by elegantly compressing it.
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?
Although an output schema exists (so return values need not be explained), the 7-parameter surface with 0% schema coverage and thin annotations leaves the description insufficient. It omits the meaning of 'path' vs 'output', overwrite behavior, and the distinction between owner and user passwords.
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?
With 0% schema description coverage across 7 parameters, the description must carry the burden but only loosely maps to 'user_password'/'owner_password' via 'a password' and to 'allow_copying'/'allow_printing' via 'restricted permissions'. It adds nothing for 'path', 'output', or 'overwrite', which are among the most consequential parameters.
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 mechanism ('Encrypt with AES-256') and names the configurable outcomes (open password, restricted permissions). It does not explicitly state that the encrypted artifact is the input document or name the sibling it complements ('unlock'), so it stops short of full sibling differentiation.
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 indication of when to choose this over 'unlock', 'redact', or 'export', and no stated preconditions (e.g., that a source file must exist at 'path'). The agent must infer all of this from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.