Skip to main content
Glama
BatuhanCakmakk

LaserPDF

by BatuhanCakmakk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Redact text

redact_pdf
Idempotent

Permanently remove all occurrences of specified words or phrases from a new PDF copy by covering them with boxes and deleting the underlying text, so they cannot be selected, searched, or copied.

Instructions

Permanently blacks out (or whites out) every occurrence of the given words or phrases in a new copy of a PDF: each is covered with a box and the text underneath is removed from the file, so it cannot be selected, searched or copied. Use it for names, numbers or other content visible on the pages; for hidden information such as the author, use remove_metadata (often both before sharing), and use search_pdf first to check what will be hit. Something under a box that cannot be cut (an image or scan) is converted to an image when flatten_unsafe is true, otherwise left hidden and reported. Returns the number of occurrences redacted; nothing is written when none is found. The original is not changed, and an existing output file is only replaced with overwrite: true. Encrypted PDFs cannot be saved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path of the PDF.
colorNoBox colour (default black).
termsYesWords or phrases to redact.
outputYesAbsolute path of the new PDF. If the file exists, the call fails unless overwrite is true.
passwordNoPassword, if the PDF is encrypted. Without it an encrypted PDF cannot be opened; with it, it can be read, but tools that write a new PDF cannot save it.
overwriteNoAllow replacing an existing file (default false).
match_caseNo
flatten_unsafeNoConvert pages with content that cannot be cut to images (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.9
    • changedInput schema / properties / output / description
      Previous value: -"Absolute path of the PDF to write."New value: +"Absolute path of the new PDF. If the file exists, the call fails unless overwrite is true."
    • changedInput schema / properties / password / description
      Previous value: -"Password, if the PDF is encrypted."New value: +"Password, if the PDF is encrypted. Without it an encrypted PDF cannot be opened; with it, it can be read, but tools that write a new PDF cannot save it."
  2. First observedv1.0.6

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond annotations: text is removed from the file (not just visually covered), the original is untouched, an existing output is replaced only with overwrite:true, encrypted PDFs cannot be saved, the occurrence count is returned, and nothing is written on a zero-match run. These are real behaviors an agent must know before calling. No contradiction with annotations - destructiveHint=false and idempotentHint=true are consistent with writing a new copy.

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?

The destructive outcome and the new-copy semantics are front-loaded in the first sentence, and the follow-up clauses each carry distinct operational information. It is a dense paragraph, though, and could be broken into shorter sentences for faster scanning.

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 write tool with no output schema, the description closes the important gaps: return value (occurrence count), failure/edge cases (encrypted PDFs, existing output file, zero matches), and the handling of uncuttable content. An agent has enough to invoke this correctly.

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?

Schema coverage is already 88%, so the schema carries most parameter meaning, but the description adds genuinely useful semantics: flatten_unsafe converts uncuttable image/scan pages to images versus leaving them hidden and reported, and overwrite governs replacement of an existing output. It does not explain match_case's default or matching behavior, which is the one remaining gap.

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?

States a specific verb and resource ('Permanently blacks out ... every occurrence of the given words or phrases in a new copy of a PDF') and immediately distinguishes the operation from nearby siblings by naming remove_metadata for hidden content and search_pdf for previewing matches.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not rules: use for visible page content, use remove_metadata for hidden metadata ('often both before sharing'), and use search_pdf first to check what will be hit. Alternatives and sequencing are stated rather than inferred.

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

Deploy Server

Other Tools