FreeDailyPro PDF Tools

pdf_redact

Read-onlyIdempotent

Permanently redact areas of a PDF. Boxes are fractions (0 to 1) of the page as displayed, measured from the top-left corner, pages numbered from 0. Text characters, picture pixels, vector art and annotations under a box are removed from the file itself and an opaque black bar is drawn; everything outside the boxes stays real, selectable text in its original fonts. A page that cannot be edited exactly (for example a curved drawing partly under a box) is turned into a picture with the boxes painted black instead. Pages without boxes are not touched

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": {
      "fileBase64": "<fileBase64>",
      "boxes": "<boxes>"
    },
    "name": "pdf_redact"
  }
}

Input Schema

Name	Required	Description	Default
`boxes`	Yes	Page index (as a string key, 0-based) -> array of boxes to redact, each in fractional page coordinates (0-1)
`fileBase64`	Yes	The PDF file, base64-encoded

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 13, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedOct 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing the actual mechanism and its limits: pixel/text/vector removal from the file itself, the black bar draw, and the fallback where a page that cannot be edited exactly (e.g., a curved drawing under a box) is rasterized with boxes painted black — a lossy side effect an agent must know about. It also states that pages without boxes are untouched, bounding the blast radius. Note the mild tension with destructiveHint=false, but since the input is supplied as base64 and no persisted resource is modified, this reads as a pure transform rather than a contradiction.

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

Conciseness5/5

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

Three sentences, front-loaded with the verb and resource, then the coordinate convention, then the fallback and the no-op case. No filler, and each clause carries an operational fact the caller needs.

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

Completeness4/5

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

For a nested two-parameter mutation tool this is nearly complete: coordinate system, page indexing, destruction semantics, rasterization fallback, and untouched pages are all covered. The remaining gap is the return value — with no output schema, the description never says what comes back (base64 PDF? a new file reference?) or how failures are reported.

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 100%, so the baseline is 3, but the description adds genuine meaning the schema omits: the origin is the top-left, coordinates are 'as displayed' (implying display orientation rather than raw PDF user space), and page keys are 0-based — all of which affect correctness of the boxes/keys mapping. It does not explain what happens with out-of-range or zero-area boxes.

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?

The opening sentence names a specific verb and resource ('Permanently redact areas of a PDF'), and the body clarifies the exact scope of the operation — content under boxes is destroyed, everything else survives as real text. It is clearly distinguishable from the sibling pptx_redact, which targets a different format.

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?

Usage is only implied: the description makes clear this is the tool for burning out regions of a PDF, but it never states when to choose it over alternatives (e.g., pptx_redact for presentations, or pdf_watermark/flatten for non-destructive overlays) or any prerequisite. An agent can infer the use case from the name and description but is given no routing guidance.

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

All FreeDailyPro PDF Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?