PDF Reader MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PDF Reader MCP Serverread the first page of the quarterly report 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 Reader MCP Server (@sylphlab/pdf-reader-mcp)
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
Using npm (Recommended)
Install as a dependency in your MCP host environment or project:
pnpm add @sylphlab/pdf-reader-mcp # Or npm install / yarn addConfigure 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:latestConfigure 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)
Clone:
git clone https://github.com/sylphlab/pdf-reader-mcp.gitInstall:
cd pdf-reader-mcp && pnpm installBuild:
pnpm run buildConfigure 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
cwdfor 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_pdftool 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
npxor Docker.✅ Robust: Uses
pdfjs-distfor 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 toolread_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.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | An array of PDF sources to process, each can optionally specify pages. | |
| include_full_text | Yes | Include the full text content of each PDF (only if 'pages' is not specified for that source). | |
| include_metadata | Yes | Include metadata and info objects for each PDF. | |
| include_page_count | Yes | Include the total number of pages for each PDF. |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
Generate and read PDFs for AI agents: a generate_pdf and a read_pdf tool, priced per document.
Parse, extract, split, and ask over digital PDFs (text layer, no OCR) from Cursor and Claude.
Extract PDFs to Markdown, RAG chunks and cited tables; publish tracked Doc Links with read stats.
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
Related MCP Servers
- AlicenseBqualityAmaintenanceEmpowers AI agents to securely read and extract information (text, metadata, page count) from PDF files within project contexts using a flexible MCP tool.1301906MIT
- FlicenseAqualityDmaintenanceEnables reading and extracting content from PDF documents including text (as Markdown), images, tables, and metadata from both local files and URLs, with OCR support for scanned documents.2
- AlicenseNot gradedqualityDmaintenanceEnables AI applications to read and process PDF files with intelligent file search, text extraction, image processing, and optional OCR support for scanned documents.MIT
- AlicenseAqualityDmaintenanceEnables reading, searching, and metadata extraction from PDF files without loading the entire content into the context window. It provides efficient tools for text cleaning, page-specific extraction, and context-aware search results.3581MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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