How do I use PDF Redaction MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PDF Redaction MCP Server Redact all credit card numbers in statement.pdf" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PDF Redaction MCP Server

by marc-hanheide

Overview Schema Related Servers Score Discussions

Python

Hybrid

PDF Redaction MCP Server

A Model Context Protocol (MCP) server that provides comprehensive PDF redaction capabilities using FastMCP and pymupdf.

Features

This MCP server enables LLMs to:

Session-based in-memory operations - load PDFs once and perform multiple operations without repeated file I/O
Load and save PDFs - explicit control over when documents are read from and written to disk
Extract text from PDFs in multiple formats (plain text, JSON, or structured blocks)
Search for text patterns using exact match or regex with location information
Redact text by search - automatically find and redact all occurrences of specified strings
Redact by coordinates - precisely redact specific areas of a PDF
Redact images - remove images from PDFs with customisable overlays
Verify redactions - confirm that sensitive information has been properly removed
Get PDF information - retrieve metadata and structure information

Related MCP server: MCP PDF Reader

Installation

Prerequisites

Python 3.10 or higher
uv (recommended) or pip

Using uv (Recommended)

# Clone or download the project
cd pdf-redaction-mcp

# Install dependencies
uv sync

# Run the server
uv run pdf-redaction-mcp

Using pip

pip install -e .
pdf-redaction-mcp

Usage

Running the Server

The server supports multiple transport modes and configurations via command-line flags:

# Show all available options
uv run pdf-redaction-mcp --help

# STDIO mode (default) - for desktop clients
uv run pdf-redaction-mcp

# SSE mode - for mobile apps and remote clients
uv run pdf-redaction-mcp --transport sse --port 8000

# HTTP mode - for web-based clients  
uv run pdf-redaction-mcp --transport http --host 0.0.0.0 --port 8080

# With custom PDF directory (relative paths resolved against this)
uv run pdf-redaction-mcp --pdf-dir /path/to/pdfs

# Combined options
uv run pdf-redaction-mcp --transport sse --port 8000 --pdf-dir ~/Documents/pdfs

Command-Line Options

--transport {stdio,http,sse}: Transport mode (default: stdio)
--host HOST: Host to bind to for HTTP/SSE mode (default: 127.0.0.1)
--port PORT: Port to listen on for HTTP/SSE mode (default: 8000)
--pdf-dir PDF_DIR: Base directory for PDF files. Relative paths in tools will be resolved against this directory.

Available Tools

All tools work with in-memory PDF documents using a session-based workflow:

Load a PDF into memory with load_pdf
Operate on it with any of the tools below
Save changes to disk with save_pdf

This approach avoids repeated file I/O and allows multiple operations on the same document efficiently.

1. `load_pdf`

Load a PDF file into memory for session-based operations.

Parameters:

pdf_path (str): Path to the PDF file to load
document_id (str, optional): Identifier for this document (defaults to filename)

Returns: JSON with document_id and basic info

Example:

load_pdf(
    pdf_path="/path/to/document.pdf",
    document_id="my_doc"
)
# Returns: {"document_id": "my_doc", "pages": 10, "status": "loaded"}

2. `save_pdf`

Save an in-memory PDF document to disk.

Parameters:

document_id (str): Identifier of the loaded document
output_path (str): Path where the PDF will be saved

Returns: JSON with save confirmation

Example:

save_pdf(
    document_id="my_doc",
    output_path="/path/to/output.pdf"
)

3. `close_pdf`

Close and remove an in-memory PDF document to free memory.

Parameters:

document_id (str): Identifier of the loaded document

Returns: JSON with close confirmation

Example:

close_pdf(document_id="my_doc")

4. `list_loaded_pdfs`

List all currently loaded PDF documents in memory.

Returns: JSON with information about all loaded documents

Example:

list_loaded_pdfs()
# Returns: {"total_documents": 2, "documents": [{...}, {...}]}

5. `extract_text_from_pdf`

Extract text from a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document
page_number (int, optional): Specific page to extract (0-indexed)
format (str): Output format - "text", "json", or "blocks"

Example:

# Load document first
load_pdf(pdf_path="/path/to/document.pdf", document_id="doc1")

# Extract all text
extract_text_from_pdf(
    document_id="doc1",
    format="text"
)

# Extract specific page as JSON
extract_text_from_pdf(
    document_id="doc1",
    page_number=0,
    format="json"
)

6. `search_text_in_pdf`

Search for text patterns and get their locations in a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document
search_string (str): Text or regex pattern to search for
case_sensitive (bool): Whether search should be case sensitive
use_regex (bool): Whether to treat search_string as regex
page_number (int, optional): Specific page to search

Example:

# Load document first
load_pdf(pdf_path="/path/to/document.pdf", document_id="doc1")

# Search for email addresses using regex
search_text_in_pdf(
    document_id="doc1",
    search_string=r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b",
    use_regex=True
)

7. `redact_text_by_search`

Automatically find and redact all occurrences of specified strings in a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document
search_strings (List[str]): List of strings to redact
fill_color (Tuple[float, float, float]): RGB colour (0-1 range)
overlay_text (str): Optional text over redacted area
text_color (Tuple[float, float, float]): RGB colour for overlay text

Example:

# Load document
load_pdf(pdf_path="/path/to/input.pdf", document_id="doc1")

# Redact sensitive information (modifies in-memory document)
redact_text_by_search(
    document_id="doc1",
    search_strings=["CONFIDENTIAL", "john.doe@example.com", "123-45-6789"],
    fill_color=(0, 0, 0),  # Black
    overlay_text="[REDACTED]"
)

# Save the redacted document
save_pdf(document_id="doc1", output_path="/path/to/redacted.pdf")

8. `redact_by_coordinates`

Redact specific areas by their exact coordinates in a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document
redactions (List[Dict]): List of redaction areas with page, bbox, and optional text
fill_color (Tuple[float, float, float]): RGB colour
overlay_text (str): Default overlay text

Example:

# Load document
load_pdf(pdf_path="/path/to/input.pdf", document_id="doc1")

# Redact specific areas (modifies in-memory document)
redact_by_coordinates(
    document_id="doc1",
    redactions=[
        {"page": 0, "bbox": [100, 100, 300, 150], "text": "REDACTED"},
        {"page": 1, "bbox": [50, 200, 250, 250]}
    ],
    fill_color=(0, 0, 0)
)

# Save the redacted document
save_pdf(document_id="doc1", output_path="/path/to/redacted.pdf")

9. `redact_images_in_pdf`

Remove all images from specified pages of a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document
page_numbers (List[int], optional): Pages to process (all if None)
fill_color (Tuple[float, float, float]): RGB colour
overlay_text (str): Text over redacted images

Example:

# Load document
load_pdf(pdf_path="/path/to/input.pdf", document_id="doc1")

# Redact all images on first two pages (modifies in-memory document)
redact_images_in_pdf(
    document_id="doc1",
    page_numbers=[0, 1],
    overlay_text="[IMAGE REMOVED]"
)

# Save the redacted document
save_pdf(document_id="doc1", output_path="/path/to/no_images.pdf")

10. `verify_redactions`

Verify that redactions were applied correctly by comparing two loaded PDF documents.

Parameters:

original_document_id (str): Identifier of the original document
redacted_document_id (str): Identifier of the redacted document
search_strings (List[str], optional): Strings that should be gone

Example:

# Load both documents
load_pdf(pdf_path="/path/to/original.pdf", document_id="original")
load_pdf(pdf_path="/path/to/redacted.pdf", document_id="redacted")

# Verify sensitive data was removed
verify_redactions(
    original_document_id="original",
    redacted_document_id="redacted",
    search_strings=["CONFIDENTIAL", "secret@example.com"]
)

11. `get_pdf_info`

Get metadata and structure information about a loaded PDF document.

Parameters:

document_id (str): Identifier of the loaded document

Example:

# Load document first
load_pdf(pdf_path="/path/to/document.pdf", document_id="doc1")

# Get PDF information
get_pdf_info(document_id="doc1")

Configuration

This section covers how to configure the PDF Redaction MCP Server with various MCP clients.

Quick Links:

Claude Desktop - Most common desktop setup
Cursor IDE - For developers using Cursor
Cline (VSCode) - VSCode MCP extension
Other MCP Clients - Generic STDIO configuration

Claude Desktop

Add to your claude_desktop_config.json:

Basic Configuration (STDIO mode):

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp"
      ]
    }
  }
}

With Custom PDF Directory:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp",
        "--pdf-dir",
        "/Users/yourname/Documents/PDFs"
      ]
    }
  }
}

This allows you to use relative paths like "document.pdf" instead of full paths.

Cursor IDE

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp"
      ]
    }
  }
}

Cline (VSCode Extension)

Add to your Cline MCP settings:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp",
        "--pdf-dir",
        "${workspaceFolder}/pdfs"
      ]
    }
  }
}

Other MCP Clients

For any MCP client supporting STDIO transport, use:

Command: uv

Args:

--directory /path/to/pdf-redaction-mcp
run
pdf-redaction-mcp
[optional flags like --pdf-dir]

Environment Variables (Optional)

For production deployments, you can use environment variables:

# Set PDF directory via environment
export PDF_DIR=/var/pdfs

# Then reference in your startup script
uv run pdf-redaction-mcp --pdf-dir "$PDF_DIR"

Real-World Configuration Examples

Example 1: Personal Use with Claude Desktop

Store all PDFs in your Documents folder:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "/Users/yourname/workspace/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp",
        "--pdf-dir",
        "/Users/yourname/Documents"
      ]
    }
  }
}

Now you can say: "Redact emails from report.pdf" instead of using full paths.

Example 2: Team Deployment with Shared PDFs

Deploy remotely with network-mounted PDF storage:

# On your server
uv run pdf-redaction-mcp \
  --transport sse \
  --host 0.0.0.0 \
  --port 8000 \
  --pdf-dir /mnt/shared-pdfs

Team members configure their clients to use the remote server.

Example 3: Development Setup

Use project-relative paths during development:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory",
        "${workspaceFolder}/pdf-redaction-mcp",
        "run",
        "pdf-redaction-mcp",
        "--pdf-dir",
        "${workspaceFolder}/test-pdfs"
      ]
    }
  }
}

Workflow Examples

Example 1: Redact Personal Information

Session-based workflow (new approach):

User: "Please redact all email addresses and phone numbers from report.pdf"

1. LLM loads the document:
   load_pdf(pdf_path="report.pdf", document_id="report")

2. LLM searches for patterns:
   search_text_in_pdf(
     document_id="report",
     search_string=r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b",
     use_regex=True
   )

3. LLM redacts in-memory:
   redact_text_by_search(
     document_id="report",
     search_strings=["john@example.com", "555-123-4567", ...]
   )

4. LLM saves the result:
   save_pdf(document_id="report", output_path="report_redacted.pdf")

5. LLM reports: "Successfully redacted 5 email addresses and 3 phone numbers"

Benefits of session-based approach:

PDF loaded once, multiple operations performed
No repeated file I/O
Can verify, modify, and re-verify without reloading

Example 2: Redact Specific Section

1. User: "Redact the financial table on page 3 of the report"

2. LLM loads document:
   load_pdf(pdf_path="report.pdf", document_id="report")

3. LLM extracts page structure:
   extract_text_from_pdf(document_id="report", page_number=2, format="blocks")

4. LLM identifies table coordinates from block structure

5. LLM redacts in-memory:
   redact_by_coordinates(
     document_id="report",
     redactions=[{"page": 2, "bbox": [100, 200, 500, 400]}]
   )

6. LLM verifies by extracting text again:
   extract_text_from_pdf(document_id="report", page_number=2)

7. LLM saves:
   save_pdf(document_id="report", output_path="report_redacted.pdf")

Example 3: Remove All Images

1. User: "Remove all images from the document but keep the text"

2. LLM loads document:
   load_pdf(pdf_path="document.pdf", document_id="doc")

3. LLM checks for images:
   get_pdf_info(document_id="doc")

4. LLM redacts images:
   redact_images_in_pdf(document_id="doc")

5. LLM verifies and saves:
   get_pdf_info(document_id="doc")  # Verify images are gone
   save_pdf(document_id="doc", output_path="document_no_images.pdf")
   
6. LLM cleans up:
   close_pdf(document_id="doc")  # Free memory

Example 4: Multi-Step Verification Workflow

1. User: "Redact all SSNs, then verify they're gone, then redact names too"

2. LLM loads document:
   load_pdf(pdf_path="sensitive.pdf", document_id="sensitive")

3. LLM redacts SSNs:
   redact_text_by_search(
     document_id="sensitive",
     search_strings=[r"\d{3}-\d{2}-\d{4}"],
     use_regex=True
   )

4. LLM creates checkpoint by saving:
   save_pdf(document_id="sensitive", output_path="sensitive_step1.pdf")

5. LLM loads original for comparison:
   load_pdf(pdf_path="sensitive.pdf", document_id="original")

6. LLM verifies:
   verify_redactions(
     original_document_id="original",
     redacted_document_id="sensitive",
     search_strings=["123-45-6789", "987-65-4321"]
   )

7. LLM continues with name redaction:
   redact_text_by_search(
     document_id="sensitive",
     search_strings=["John Doe", "Jane Smith"]
   )

8. LLM saves final version:
   save_pdf(document_id="sensitive", output_path="sensitive_final.pdf")

9. LLM cleans up:
   close_pdf(document_id="original")
   close_pdf(document_id="sensitive")

LLM verifies using get_pdf_info that images are gone




---

## Troubleshooting

### Claude Desktop Connection Issues

**Problem:** MCP server not connecting in Claude Desktop

**Solutions:**
1. Verify the path in `claude_desktop_config.json` is correct:
   ```bash
   # Check if the directory exists
   ls -la /path/to/pdf-redaction-mcp

Test the server manually:

cd /path/to/pdf-redaction-mcp
uv run pdf-redaction-mcp --help

Check Claude Desktop logs:
- macOS: ~/Library/Logs/Claude/
- Windows: %APPDATA%\Claude\logs\
- Linux: ~/.config/Claude/logs/

PDF Path Issues

Problem: "File not found" errors when using relative paths

Solution: Configure --pdf-dir flag in your MCP client config:

{
  "mcpServers": {
    "pdf-redaction": {
      "command": "uv",
      "args": [
        "--directory", "/path/to/pdf-redaction-mcp",
        "run", "pdf-redaction-mcp",
        "--pdf-dir", "/your/pdf/directory"
      ]
    }
  }
}

Port Already in Use (HTTP/SSE mode)

Problem: Address already in use error when starting server

Solution:

Use a different port:

uv run pdf-redaction-mcp --transport sse --port 8001

Or find and kill the process using the port:

# macOS/Linux
lsof -ti:8000 | xargs kill -9

# Windows
netstat -ano | findstr :8000
taskkill /PID <PID> /F

UV Not Found

Problem: uv: command not found

Solution: Install UV package manager:

# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# Or use pip
pip install uv

Development

Running Tests

uv run pytest

Project Structure

pdf-redaction-mcp/
├── src/
│   └── pdf_redaction_mcp/
│       ├── __init__.py
│       └── server.py          # Main MCP server implementation
├── tests/
│   └── test_server.py         # Unit tests
├── pyproject.toml             # Project dependencies
└── README.md                  # This file

Technical Details

Redaction Implementation

The server uses pymupdf's redaction annotations, which:

Add redaction annotations to mark areas for removal
Apply redactions to permanently remove content
Cannot be undone once saved - content is truly deleted from PDF structure

Colour Format

Colours are specified as RGB tuples with values from 0 to 1:

Black: (0, 0, 0)
White: (1, 1, 1)
Red: (1, 0, 0)
Green: (0, 1, 0)
Blue: (0, 0, 1)

Coordinate System

PDF coordinates use bottom-left origin:

x0, y0: Bottom-left corner of rectangle
x1, y1: Top-right corner of rectangle

Bounding boxes: [x0, y0, x1, y1]

Security Considerations

Permanent Removal: Redactions permanently remove content from PDF structure
Verify Redactions: Always use verify_redactions to confirm sensitive data is gone
Backup Original: Keep original files backed up before redacting
File Paths: Ensure proper file path validation in production
Access Control: Implement appropriate access controls for sensitive documents

Limitations

Only works with PDF files (use pymupdf's supported formats)
Encrypted PDFs may require password authentication
Very large PDFs may require significant memory
Redactions are permanent once saved

Contributing

Contributions are welcome! Please ensure:

Code follows existing style
Tests pass (uv run pytest)
Documentation is updated
Commit messages are clear

Licence

MIT Licence - see LICENCE file for details

Acknowledgements

FastMCP - MCP framework
pymupdf - PDF manipulation library
Model Context Protocol - MCP specification

Support

For issues, questions, or contributions:

Open an issue on GitHub
Check the FastMCP documentation
Check the pymupdf documentation

Available Tools

11 tools

close_pdfA

Close and remove an in-memory PDF document.

Use this to free up memory when you're done with a document. Any unsaved changes will be lost.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Identifier of the loaded document

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description discloses the destructive side effect: 'Any unsaved changes will be lost.' It also clarifies the scope ('in-memory') and the purpose of freeing memory, which is not present in the schema.

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, each with a distinct purpose: state the action, give usage context, and warn about data loss. No fluff.

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 simple close operation, the description covers the action, when to use it, and the key side effect. The output schema is provided separately, so the description needn't explain return values.

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

Parameters3/5

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

Schema coverage is 100%; the description adds no additional explanation for document_id beyond the schema's 'Identifier of the loaded document.' Therefore, the baseline of 3 applies.

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 description uses a specific verb 'close and remove' and clearly identifies the resource ('in-memory PDF document'), distinguishing it from sibling tools like load_pdf or save_pdf. It also states the effect of freeing memory.

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?

The description explicitly states 'Use this to free up memory when you're done with a document,' providing a clear condition for when to invoke the tool. It also implicitly advises saving first with the warning about unsaved changes, but doesn't name alternative tools.

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

extract_text_from_pdfA

Extract text from a loaded PDF document.

The document must be loaded first using load_pdf.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format - "text" (plain text), "json" (structured), or "blocks" (text blocks)	text
`document_id`	Yes	Identifier of the loaded document
`page_number`	No	Specific page number to extract (0-indexed). If None, extracts all pages

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose a key prerequisite (the document must be loaded), but it does not explicitly state that this is a read-only operation, nor does it describe behavior on invalid document IDs or large documents. The prerequisite is valuable, but more behavioral context would be expected given the lack of annotations.

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?

The description is two short sentences that are front-loaded with the core action and followed by the key prerequisite. Every sentence earns its place, making it highly concise and easy to scan.

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?

The description covers the essential prerequisite and the schema fully documents all parameters. An output schema exists, so return values do not require explanation. However, the description does not mention alternative tools or potential error conditions, leaving some contextual gaps for an agent choosing the right tool.

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

Parameters3/5

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

Schema description coverage is 100%, with all three parameters (format, document_id, page_number) having clear descriptions. The tool description adds no parameter-specific information beyond the schema, so it meets the baseline expectation but does not exceed it.

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 description clearly states the tool's function: 'Extract text from a loaded PDF document.' It uses a specific verb and resource, and the prerequisite of a loaded document adds precision. This distinguishes it from sibling tools like load_pdf, search_text_in_pdf, and redact_by_coordinates, which have different purposes.

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?

The description explicitly states a necessary precondition: 'The document must be loaded first using load_pdf.' This gives clear sequential usage context. However, it does not discuss when to prefer this tool over alternatives like search_text_in_pdf or get_pdf_info, so it falls short of a full usage guideline.

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

get_pdf_infoA

Get basic information about a loaded PDF document.

The document must be loaded first using load_pdf.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Identifier of the loaded document

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the loading prerequisite but does not explicitly state that the operation is read-only, has no side effects, or explain behavior with invalid document IDs. The tone suggests a getter, but this is not made explicit.

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?

The description is two sentences, front-loaded with the core purpose, and contains zero fluff. The prerequisite is stated efficiently without repetition. It is an excellent example of conciseness.

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?

Given the tool's simplicity (1 parameter, output schema exists), the description covers the essential context: what it does and the necessary prerequisite. However, it could be slightly more complete by contrasting with list_loaded_pdfs (e.g., 'Use for a single document, not enumeration') to help the agent choose among siblings. No output schema explanation is needed since one exists.

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?

The schema description for document_id is already clear ('Identifier of the loaded document'), and the tool description enhances it by clarifying that the document must be loaded first using load_pdf. This adds contextual meaning to the parameter, helping the agent understand valid input values beyond the raw schema.

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 description clearly states the tool's function: 'Get basic information about a loaded PDF document.' The verb 'get' with resource 'loaded PDF document' is specific and distinct from sibling tools like extract_text_from_pdf or list_loaded_pdfs. It immediately sets expectations.

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?

The description provides a clear prerequisite: 'The document must be loaded first using load_pdf.' This indicates when to use the tool, but it does not explicitly contrast with alternatives or mention when not to use it. The guidance is present but minimal compared to examples like get_calls.

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

list_loaded_pdfsA

List all currently loaded PDF documents in memory.

Returns: JSON string with information about all loaded documents

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of disclosing behavior. It clarifies that the operation is non-mutating (listing) and specifies the return format (JSON string). It does not explicitly state 'does not modify documents,' but 'list' inherently implies read-only, and the description adds useful context.

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?

The description is two sentences, front-loads the main purpose, and includes relevant return information without any wasted words. Ideal conciseness.

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?

Given the tool's simplicity (no parameters) and the presence of an output schema, the description is complete. It covers the essential action and return type without needing to explain parameters or elaborate on return values.

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?

The tool has zero parameters, so there is nothing to explain. Per the rubric, a baseline of 4 is appropriate for a 0-parameter tool.

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 description states a specific action ('List') on a specific resource ('currently loaded PDF documents') with a scope ('in memory'). This unambiguously distinguishes it from sibling tools like load_pdf or save_pdf.

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?

The context clearly implies when to use this tool (when you need to see which PDFs are loaded), but it does not explicitly mention alternatives or exclusions. Since the description is clear enough for a simple tool, it earns a 4.

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

load_pdfA

Load a PDF file into memory for session-based operations.

All other PDF tools in the MCP server require a document to be loaded first using this tool. The document remains in memory until saved or the session ends.

ParametersJSON Schema

Name	Required	Description	Default
`pdf_path`	Yes	Path to the PDF file to load
`document_id`	No	Optional identifier for this document. If None, uses the filename

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It states that the document remains in memory until saved or the session ends, which is key behavior beyond the obvious load action. However, it does not mention error handling or access requirements, so it's not a 5.

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?

The description is composed of three concise, purposeful sentences: the core action, the prerequisite relationship, and the memory lifetime. Every sentence adds necessary information without redundancy.

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 simple load tool, the description fully covers its role among the sibling tools, the mandatory usage prerequisite, and the in-memory lifetime. An output schema exists, so return values need not be described. The description is complete for its complexity.

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

Parameters3/5

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

The input schema already provides descriptions for both pdf_path and document_id, achieving 100% schema description coverage. The tool description adds no parameter-specific details, so the baseline of 3 applies.

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 description uses a specific verb 'Load' and resource 'PDF file into memory', and explicitly states that all other PDF tools require this tool first, which clearly distinguishes it from siblings like extract_text_from_pdf and redact_text_by_search.

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?

The description gives clear context that this tool is a prerequisite for all other PDF tools, but it does not explicitly provide when-not-to-use guidance or name alternative tools, stopping short of a 5.

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

redact_by_coordinatesA

Redact specific areas of a loaded PDF document by coordinates.

The document must be loaded first using load_pdf. Modifications are made in-memory. Use save_pdf to write the changes to disk.

ParametersJSON Schema

Name	Required	Description
`fill_color`	No	RGB color for redaction box (0-1 range). Default is black (0,0,0)
`redactions`	Yes	List of redaction areas, each with: - page: Page number (0-indexed) - bbox: Bounding box as [x0, y0, x1, y1] - text: Optional overlay text for this specific redaction
`document_id`	Yes	Identifier of the loaded document
`overlay_text`	No	Default text to display over redacted areas (can be overridden per redaction)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavioral traits. It does mention in-memory modification and the need to save, which is useful, but omits the irreversible nature of redaction once saved and does not specify coordinate system semantics or side effects beyond persistence. This is a moderate disclosure level.

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?

The description is three sentences: a clear purpose statement followed by two essential workflow constraints. Every sentence adds value, no filler or redundant content.

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?

The description covers the required prerequisites and persistence workflow (load first, in-memory, save to disk). The presence of an output schema means return values need not be explained. It lacks details about coordinate system semantics, but overall it provides enough context for correct invocation in a multi-step PDF workflow.

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

Parameters3/5

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

The schema already provides 100% description coverage for all parameters, including detailed descriptions for redactions, fill_color, and overlay_text. The tool description adds little beyond the phrase 'by coordinates' and does not clarify coordinate origin or units, but the baseline of 3 is appropriate because the schema carries the semantic load.

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 description explicitly states the tool redacts specific areas of a loaded PDF by coordinates, which is a distinct verb+resource+method combination. It also differentiates from sibling redaction tools that target text or images by naming the coordinate-based approach.

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?

The description gives clear prerequisites and workflow: the document must be loaded first, modifications are in-memory, and save_pdf is required to persist changes. It does not explicitly name alternatives like redact_text_by_search or redact_images_in_pdf, but the coordinate-based scope is implied.

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

redact_images_in_pdfA

Redact all images in specified pages of a loaded PDF document.

The document must be loaded first using load_pdf. Modifications are made in-memory. Use save_pdf to write the changes to disk.

ParametersJSON Schema

Name	Required	Description	Default
`fill_color`	No	RGB color for redaction box (0-1 range). Default is black (0,0,0)
`document_id`	Yes	Identifier of the loaded document
`overlay_text`	No	Text to display over redacted images	[IMAGE REDACTED]
`page_numbers`	No	List of page numbers to process (0-indexed). If None, processes all pages

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden of disclosing side effects. It clearly states that modifications are in-memory and require an explicit save to persist, which is essential for a mutating operation. It does not detail the irreversible nature of redaction after saving, but the save step implies this.

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?

The description is three sentences long, front-loads the primary purpose, and provides necessary workflow context without any redundant information. Every sentence earns its place.

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?

Given the large sibling set and the tool's complexity, the description covers the necessary context: how to load, modify, and save. It does not explain the full effect of redaction (e.g., underlying content is destroyed), but with a detailed schema and output schema present, this is adequate.

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

Parameters3/5

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

Schema descriptions cover 100% of the parameters, so the baseline is 3. The description does not add additional semantic details about parameters beyond what the schema already provides, but it does not need to.

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 description clearly states the tool's function ('Redact all images in specified pages') with a specific verb and resource, and differentiates from sibling redaction tools by focusing on images. The distinction from redact_text_by_search and redact_by_coordinates is evident from the purpose.

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?

The description provides clear workflow guidance: the document must be loaded via load_pdf first, and changes are saved with save_pdf. It does not explicitly name alternatives, but the tool's purpose and sibling context make the appropriate use cases clear.

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

redact_text_by_searchA

Redact all occurrences of specified text strings in a loaded PDF document.

The document must be loaded first using load_pdf. Modifications are made in-memory. Use save_pdf to write the changes to disk.

ParametersJSON Schema

Name	Required	Description
`fill_color`	No	RGB color for redaction box (0-1 range). Default is black (0,0,0)
`text_color`	No	RGB color for overlay text (0-1 range). Default is white (1,1,1)
`document_id`	Yes	Identifier of the loaded document
`overlay_text`	No	Optional text to display over redacted area, use this to explain what has been redacted here
`search_strings`	Yes	List of strings to search for and redact

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of explaining behavior. It discloses that modifications are in-memory and require save_pdf, which is valuable context. However, it does not mention irreversibility, appearance of redaction, or whether text is physically removed, leaving gaps in transparency.

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?

The description is three sentences, front-loaded with the core action, followed by essential workflow notes. No redundant or unnecessary information is present; every sentence earns its place.

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?

The tool is part of a clear workflow (load, redact, save), and the description covers both prerequisite and saving steps. An output schema exists, so return values need not be explained. It lacks only explicit guidance on choosing this tool over coordinate-based redaction, but overall is sufficiently complete for the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter has its own description in the schema. The tool description adds little beyond clarifying that search_strings are 'specified text strings' and the document must be loaded, but the schema already handles parameter meaning effectively.

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 description clearly states the tool redacts all occurrences of specified text strings in a loaded PDF, using a specific verb and resource. It distinguishes itself from sibling tools like redact_by_coordinates and redact_images by focusing on text-based redaction.

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?

The description provides clear workflow context: the document must be loaded first using load_pdf, and changes must be saved via save_pdf. While it does not explicitly mention alternatives like redact_by_coordinates, the prerequisites and persistence steps are clearly communicated.

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

save_pdfA

Save an in-memory PDF document to disk.

The document remains loaded in memory after saving and can continue to be modified.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Identifier of the loaded document
`output_path`	Yes	Path where the PDF will be saved

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Since no annotations are provided, the description must carry the behavioral burden. It does disclose a key behavior: the document remains in memory and can be modified after saving. But it omits other potentially relevant details such as whether the file will be overwritten, permission requirements, or error behaviors. This adds some transparency but not a rich behavioral picture.

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?

The description is two sentences, with the primary action front-loaded and the second sentence providing valuable behavioral context. There is no redundancy or filler, making it concise and well-structured.

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 narrowly scoped save operation with two well-documented parameters and an output schema, the description covers the essential information for selection and invocation. It could mention overwrite behavior or error handling, but such details are not critical for the tool's basic use. Overall, it is sufficiently complete.

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

Parameters3/5

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

The input schema already fully documents both parameters with clear descriptions (document_id and output_path), and schema coverage is 100%. The description adds no additional parameter-level information, so the baseline score of 3 is appropriate.

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 description uses a specific verb 'Save' with the resource 'in-memory PDF document' and destination 'disk', clearly distinguishing it from sibling tools like load_pdf, close_pdf, or redact functions. The phrase 'in-memory' also clarifies that the document must already be loaded, which is a distinct context.

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?

The description clearly implies when to use the tool: when you have an in-memory PDF document and want to persist it to disk. It notes that the document remains loaded after saving, which implicitly contrasts with close_pdf. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

search_text_in_pdfA

Search for text in a loaded PDF document and return all occurrences with their locations.

The document must be loaded first using load_pdf.

ParametersJSON Schema

Name	Required	Description
`use_regex`	No	Whether to treat search_string as a regex pattern
`document_id`	Yes	Identifier of the loaded document
`page_number`	No	Specific page to search (0-indexed). If None, searches all pages
`search_string`	Yes	Text or regex pattern to search for
`case_sensitive`	No	Whether search should be case sensitive

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool searches for text and returns locations, and notes the dependency on a prior load_pdf call. This goes beyond the schema by explaining the output content and a state requirement, though it could explicitly state non-destructive behavior.

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?

The description is two sentences, front-loaded with the core action, and every sentence adds value. No wasted words.

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?

Given the presence of an output schema and full parameter descriptions, the description only needs to cover the tool's main behavior and prerequisites. It does that effectively, making the tool usable without missing critical context. A small gap is the lack of error-handling behavior (e.g., invalid document_id), but that is not essential.

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

Parameters3/5

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

Schema coverage is 100%, with each parameter having a description. The tool description does not add parameter-specific meanings beyond what is already in the schema. According to the rubric, a baseline of 3 is appropriate when the schema provides full coverage.

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 description clearly states the tool's function with a specific verb ('Search') and resource ('loaded PDF document'), and specifies the output ('all occurrences with their locations'). This distinguishes it from sibling tools like extract_text_from_pdf or redact_text_by_search.

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?

The description provides a clear prerequisite: 'The document must be loaded first using load_pdf.' This gives context on when the tool can be used. It does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous enough that no exclusions are necessary.

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

verify_redactionsA

Verify that redactions were applied correctly by comparing two loaded PDF documents.

Both documents must be loaded first using load_pdf.

ParametersJSON Schema

Name	Required	Description
`search_strings`	No	Optional list of strings that should no longer appear in redacted PDF
`original_document_id`	Yes	Identifier of the original document
`redacted_document_id`	Yes	Identifier of the redacted document

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the prerequisite and the comparative nature of the operation, but it does not mention whether the tool is read-only, what happens if documents are not loaded, or how search_strings are used beyond the schema description. This leaves some behavioral gaps.

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?

The description is two concise sentences, front-loaded with the primary action and a clear prerequisite. No wasted words; every sentence earns its place. It is appropriately sized for the tool's simplicity.

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?

With a complete input schema and an output schema present, the description is sufficiently complete for the tool's moderate complexity. It covers the purpose and the prerequisite. The only minor gap is not explicitly tying search_strings to the comparison, but the schema's description of that parameter fills the gap.

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

Parameters3/5

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

All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds the contextual note that documents must be loaded first, but it does not add extra meaning to the individual parameters beyond what the schema already provides. The search_strings parameter is only explained in the schema, which is adequate.

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 description uses a specific verb ('Verify') and resource ('redactions') and explains the method ('comparing two loaded PDF documents'). It clearly distinguishes the tool from siblings like redact_text_by_search or search_text_in_pdf, and the prerequisite of loading documents first is stated, making the purpose unambiguous.

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?

The description explicitly states that both documents must be loaded first using load_pdf, providing a clear precondition for use. It implies usage after redaction ('verify that redactions were applied correctly'). It does not explicitly list alternatives or when-not-to-use, but the context is sufficient for a well-defined workflow.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct operation: loading, saving, closing, extracting, searching, redacting by text/coordinates/images, verifying, and info. The redaction tools are clearly differentiated by their method. No two tools appear to overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., load_pdf, save_pdf, redact_by_coordinates). The naming is uniform and predictable, with no mixed conventions or vague verbs.

Tool Count5/5

With 11 tools, the server is well-scoped for PDF redaction workflows. Each tool has a clear role and the count is neither excessive nor too sparse. The coverage balances core redaction operations with supporting utilities like verification and info.

Completeness5/5

The tool set covers the full lifecycle of PDF redaction: loading, inspecting, redacting via multiple methods, verifying, saving, and closing. There are no obvious gaps for the stated purpose, and auxiliary features like search and extraction round out the domain nicely.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PDF Redaction MCP A
com.pdf-redaction
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
File Systems Security
23
mcp-server
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1
PDF to Markdown (pdf2md.dev)
dev.pdf2md
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
AI & Machine Learning Image & Video Processing
2
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31

Related MCP Servers

PDF Reader MCP Server
Documentation Access Data Platforms
pablontiv
F
license
A
quality
Not graded
maintenance
A Model Context Protocol server that extracts and processes content from PDF documents, providing text extraction, metadata retrieval, page-level processing, and PDF validation capabilities.
Updated a year ago (2025-08-04 17:52 UTC)
4
1
MCP PDF Reader
Documentation Access File Systems Research & Data
rturv
A
license
A
quality
C
maintenance
A Model Context Protocol server that enables the extraction of text, metadata, and embedded images from PDF files. It provides tools for searching text with context, reading specific pages, and counting total pages within a document.
Updated 8 months ago (2026-01-16 08:49 UTC)
7
29
1
MIT
pdf-mcp
Documentation Access File Systems Research & Data
I-CAN-hack
A
license
A
quality
C
maintenance
An MCP server for reading, rendering, and searching PDF files, specifically optimized for LLMs to extract text, tables, and technical diagrams. It enables metadata retrieval, multi-format text extraction, and page-to-image rendering using PyMuPDF.
Updated a month ago (2026-07-30 09:07 UTC)
5
77
MIT
RAG-Anything MCP Server
RAG Systems Knowledge & Memory Search
nguyenngocdue
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables any MCP-compatible application to perform advanced multi-modal document processing and retrieval using RAG-Anything.
Updated 8 months ago (2026-01-13 15:17 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marc-hanheide/pdf-redaction-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

PDF Redaction MCP Server

Features

Installation

Prerequisites

Using uv (Recommended)

Using pip

Usage

Running the Server

Command-Line Options

Available Tools

1. load_pdf

2. save_pdf

3. close_pdf

4. list_loaded_pdfs

5. extract_text_from_pdf

6. search_text_in_pdf

7. redact_text_by_search

8. redact_by_coordinates

9. redact_images_in_pdf

10. verify_redactions

11. get_pdf_info

Configuration

Claude Desktop

Cursor IDE

Cline (VSCode Extension)

Other MCP Clients

Environment Variables (Optional)

Real-World Configuration Examples

Workflow Examples

Example 1: Redact Personal Information

Example 2: Redact Specific Section

Example 3: Remove All Images

Example 4: Multi-Step Verification Workflow

PDF Path Issues

Port Already in Use (HTTP/SSE mode)

UV Not Found

Development

Running Tests

Project Structure

Technical Details

Redaction Implementation

Colour Format

Coordinate System

Security Considerations

Limitations

Contributing

Licence

Acknowledgements

Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `load_pdf`

2. `save_pdf`

3. `close_pdf`

4. `list_loaded_pdfs`

5. `extract_text_from_pdf`

6. `search_text_in_pdf`

7. `redact_text_by_search`

8. `redact_by_coordinates`

9. `redact_images_in_pdf`

10. `verify_redactions`

11. `get_pdf_info`