Skip to main content
Glama

PDF Reader MCP Server (@sylphlab/pdf-reader-mcp)

CI/CD Pipeline codecov npm version Docker Pulls License: MIT

Empower your AI agents (like Cline) with the ability to securely read and extract information (text, metadata, page count) from PDF files within your project context using a single, flexible tool.

Installation

Install as a dependency in your MCP host environment or project:

pnpm add @sylphlab/pdf-reader-mcp # Or npm install / yarn add

Configure your MCP host (e.g., mcp_settings.json) to use npx:

{
  "mcpServers": {
    "pdf-reader-mcp": {
      "command": "npx",
      "args": ["@sylphlab/pdf-reader-mcp"],
      "name": "PDF Reader (npx)"
    }
  }
}

(Ensure the host sets the correct cwd for the target project)

Using Docker

Pull the image:

docker pull sylphlab/pdf-reader-mcp:latest

Configure your MCP host to run the container, mounting your project directory to /app:

{
  "mcpServers": {
    "pdf-reader-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-v",
        "/path/to/your/project:/app", // Or use "$PWD:/app", "%CD%:/app", etc.
        "sylphlab/pdf-reader-mcp:latest"
      ],
      "name": "PDF Reader (Docker)"
    }
  }
}

Local Build (For Development)

  1. Clone: git clone https://github.com/sylphlab/pdf-reader-mcp.git

  2. Install: cd pdf-reader-mcp && pnpm install

  3. Build: pnpm run build

  4. Configure MCP Host:

    {
      "mcpServers": {
        "pdf-reader-mcp": {
          "command": "node",
          "args": ["/path/to/cloned/repo/pdf-reader-mcp/build/index.js"],
          "name": "PDF Reader (Local Build)"
        }
      }
    }

    (Ensure the host sets the correct cwd for the target project)

Related MCP server: PDF Reader MCP Server

Quick Start

Assuming the server is running and configured in your MCP host:

MCP Request (Get metadata and page 2 text from a local PDF):

{
  "tool_name": "read_pdf",
  "arguments": {
    "sources": [
      {
        "path": "./documents/my_report.pdf",
        "pages": [2]
      }
    ],
    "include_metadata": true,
    "include_page_count": false, // Default is true, explicitly false here
    "include_full_text": false // Ignored because 'pages' is specified
  }
}

Expected Response Snippet:

{
  "results": [
    {
      "source": "./documents/my_report.pdf",
      "success": true,
      "data": {
        "page_texts": [
          { "page": 2, "text": "Text content from page 2..." }
        ],
        "info": { ... },
        "metadata": { ... }
        // num_pages not included as requested
      }
    }
  ]
}

Why Choose This Project?

  • 🛡️ Secure: Confines file access strictly to the project root directory.

  • 🌐 Flexible: Handles both local relative paths and public URLs.

  • 🧩 Consolidated: A single read_pdf tool serves multiple extraction needs (full text, specific pages, metadata, page count).

  • ⚙️ Structured Output: Returns data in a predictable JSON format, easy for agents to parse.

  • 🚀 Easy Integration: Designed for seamless use within MCP environments via npx or Docker.

  • ✅ Robust: Uses pdfjs-dist for reliable parsing and Zod for input validation.

Performance Advantages

Initial benchmarks using Vitest on a sample PDF show efficient handling of various operations:

Scenario

Operations per Second (hz)

Relative Speed

Handle Non-Existent File

~12,933

Fastest

Get Full Text

~5,575

Get Specific Page (Page 1)

~5,329

Get Specific Pages (Pages 1 & 2)

~5,242

Get Metadata & Page Count

~4,912

Slowest

(Higher hz indicates better performance. Results may vary based on PDF complexity and environment.)

See the Performance Documentation for more details and future plans.

Features

  • Read full text content from PDF files.

  • Read text content from specific pages or page ranges.

  • Read PDF metadata (author, title, creation date, etc.).

  • Get the total page count of a PDF.

  • Process multiple PDF sources (local paths or URLs) in a single request.

  • Securely operates within the defined project root.

  • Provides structured JSON output via MCP.

  • Available via npm and Docker Hub.

Design Philosophy

The server prioritizes security through context confinement, efficiency via structured data transfer, and simplicity for easy integration into AI agent workflows. It aims for minimal dependencies, relying on the robust pdfjs-dist library.

See the full Design Philosophy documentation.

Comparison with Other Solutions

Compared to direct file access (often infeasible) or generic filesystem tools, this server offers PDF-specific parsing capabilities. Unlike external CLI tools (e.g., pdftotext), it provides a secure, integrated MCP interface with structured output, enhancing reliability and ease of use for AI agents.

See the full Comparison documentation.

Future Plans (Roadmap)

  • Documentation:

    • Finalize all documentation sections (Guide, API, Design, Comparison).

    • Resolve TypeDoc issue and generate API documentation.

    • Add more examples and advanced usage patterns.

    • Implement PWA support and mobile optimization for the docs site.

    • Add share buttons and growth metrics to the docs site.

  • Benchmarking:

    • Conduct comprehensive benchmarks with diverse PDF files (size, complexity).

    • Measure memory usage.

    • Compare URL vs. local file performance.

  • Core Functionality:

    • Explore potential optimizations for very large PDF files.

    • Investigate options for extracting images or annotations (longer term).

  • Testing:

    • Increase test coverage towards 100% where practical.

    • Add runtime tests once feasible.

Documentation

For detailed usage, API reference, and guides, please visit the Full Documentation Website (Link to be updated upon deployment).

Community & Support

  • Found a bug or have a feature request? Please open an issue on GitHub Issues.

  • Want to contribute? We welcome contributions! Please see CONTRIBUTING.md.

  • Star & Watch: If you find this project useful, please consider starring ⭐ and watching 👀 the repository on GitHub to show your support and stay updated!

License

This project is licensed under the MIT License.

Available Tools

1 tool
read_pdfA

Reads content/metadata from PDFs. Paths must be relative to the project root. Project root can be set via: 1) --root command line argument, 2) PDF_READER_MCP_ROOT environment variable, or 3) process.cwd() (default). Absolute paths in the path parameter are rejected.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourcesYesAn array of PDF sources to process, each can optionally specify pages.
include_full_textYesInclude the full text content of each PDF (only if 'pages' is not specified for that source).
include_metadataYesInclude metadata and info objects for each PDF.
include_page_countYesInclude the total number of pages for each PDF.

TDQS

A3.7/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 of behavioral disclosure. It effectively describes key behaviors: it reads (not writes) PDFs, requires relative paths, rejects absolute paths, and explains project root configuration. It doesn't cover rate limits or error handling, but provides substantial operational context.

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 description is appropriately concise and front-loaded: the first sentence states the core purpose, followed by essential operational details. Every sentence adds value, though it could be slightly more structured for readability.

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 complexity (4 parameters, no output schema, no annotations), the description provides good contextual completeness. It explains the tool's purpose, path handling, and configuration, though it doesn't detail return values or error cases, which would be helpful without an output schema.

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%, so the schema already documents all parameters thoroughly. The description adds no specific parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Reads content/metadata from PDFs.' It specifies the verb ('reads') and resource ('PDFs'), making the function unambiguous. However, it doesn't differentiate from siblings since there are none, so it can't achieve a perfect score of 5.

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 implicit usage guidance by explaining path requirements and configuration options (e.g., relative paths, project root settings). However, it lacks explicit when-to-use guidance or comparisons with alternatives, as there are no sibling tools to reference.

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

TDQS

A3.6/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'read_pdf' has a clear and distinct purpose that cannot be confused with any other tool in this set.

Naming Consistency5/5

The single tool name 'read_pdf' follows a clear verb_noun pattern, and with only one tool, consistency is inherently perfect as there are no other names to compare against.

Tool Count2/5

A single tool is too few for a server named 'PDF Reader MCP Server', which implies broader PDF-related functionality. This minimal set feels thin and under-scoped for the apparent domain, limiting agent capabilities.

Completeness2/5

The tool surface is severely incomplete for a PDF reader domain. While 'read_pdf' handles content extraction, there are obvious gaps such as no tools for creating, editing, merging, splitting, or searching PDFs, which are common operations in this context.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/cydynamic/pdf-reader-mcp'

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