MCP PDF Extract
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., "@MCP PDF Extractlist all PDF documents"
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.
MCP PDF Extract
A Model Context Protocol (MCP) server that provides PDF document reading capabilities. This server allows MCP clients to list and read PDF documents from a specified directory.
Architecture
graph TB
subgraph "MCP Client Layer"
Client[MCP Client<br/>Claude Desktop / Inspector]
end
subgraph "MCP Server Layer"
Server[MCP Documents Server<br/>mcp_documents_server.py]
FastMCP[FastMCP Framework]
Server --> FastMCP
end
subgraph "Business Logic Layer"
PDFLoader[PDF Loader<br/>pdf.py]
Exceptions[Exception Handler<br/>app/exceptions.py]
PDFLoader --> Exceptions
end
subgraph "Data Layer"
PDFFiles[PDF Files<br/>data/pdfs/]
EnvConfig[Environment Config<br/>.env]
end
Client <-->|"JSON-RPC over stdio"| Server
Server -->|"Tools & Resources"| PDFLoader
PDFLoader -->|"Async Read"| PDFFiles
PDFLoader -->|"Config"| EnvConfig
style Client fill:#e1f5fe
style Server fill:#fff3e0
style PDFLoader fill:#f3e5f5
style PDFFiles fill:#e8f5e9Component Communication
sequenceDiagram
participant C as MCP Client
participant S as MCP Server
participant P as PDF Loader
participant F as File System
C->>S: Initialize connection
S-->>C: Server capabilities
C->>S: List documents (resource)
S->>P: list_available_pdfs()
P->>F: Read directory
F-->>P: PDF file list
P-->>S: Document metadata
S-->>C: Document list
C->>S: Read document (tool)
S->>P: load_pdf(doc_id)
P->>F: Read PDF file
P->>P: Extract text
P-->>S: Document content
S-->>C: PDF text contentRelated MCP server: PDF Reader MCP Server
Features
List available PDF documents
Read and extract text content from PDF files
File size validation
Path traversal protection
Configurable PDF directory and size limits
Prerequisites
Python 3.10 or higher
uvpackage manager (recommended)
Installation
1. Clone the repository
cd /path/to/your/projects
git clone <repository-url>
cd MCP_pdf_extract2. Create virtual environment and install dependencies
Using uv (recommended):
# Install uv if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh
# Create virtual environment
uv venv
# Sync dependencies
uv sync3. Set up environment variables
Create a .env file in the project root:
MAX_PDF_SIZE_KB=350
PDF_DIR=./data/pdfs4. Create PDF directory
mkdir -p data/pdfsPlace your PDF files in the data/pdfs directory.
Running the Server
Basic execution
uv run python mcp_documents_server.pyTesting with MCP Inspector
To test the server with the MCP Inspector:
npx @modelcontextprotocol/inspectorIn the Inspector interface:
Command:
uvArguments:
run --with mcp mcp run mcp_documents_server.py
Verify the server is running
To verify the server is responding correctly, you can send a test message:
echo '{"jsonrpc": "2.0", "method": "initialize", "params": {"capabilities": {}}, "id": 1}' | uv run python mcp_documents_server.pyYou should see a JSON response from the server.
Available Resources and Tools
Resources
docs://documents- Lists all available PDF documentsdocs://documents/{doc_id}- Fetches the content of a specific PDF document
Tools
read_doc_contents- Reads and returns the text content of a PDF documentParameter:
doc_id(string) - The filename of the PDF to read
Configuration
The server can be configured using environment variables:
PDF_DIR: Directory containing PDF files (default:./data/pdfs)MAX_PDF_SIZE_KB: Maximum allowed PDF file size in KB (default: 350)
Integration with MCP Clients
Claude Desktop
Add the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"pdf-extractor": {
"command": "uv",
"args": ["--directory", "/path/to/MCP_pdf_extract", "run", "python", "mcp_documents_server.py"],
"env": {}
}
}
}Troubleshooting
Ensure Python 3.10+ is installed:
python --versionVerify uv is installed:
uv --versionCheck that PDF files are in the correct directory:
ls data/pdfs/Ensure the virtual environment is activated when running commands
License
[Your license here]
Available Tools
2 toolslist_available_pdfsB
List all available PDF documents that can be read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists PDFs, implying a read-only operation. However, it does not disclose what 'available' means, whether the list is static or dynamic, or any side effects. The description is honest but lacks depth.
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?
A single sentence of 8 words with no redundancy. Every word is necessary. It is appropriately brief for a parameterless tool.
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?
No output schema is provided, and the description does not describe the return format (e.g., file names, paths, IDs). The tool is simple, but the agent needs to know what the output looks like to use it effectively, especially to feed into the sibling 'read_doc_contents'. This gap reduces completeness.
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?
The tool has zero parameters, so the schema is fully descriptive. The description adds slight value by stating the list is of 'all available PDF documents', implying no filtering. Baseline for 0 parameters is 4, and this is met.
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 action ('List') and the resource ('all available PDF documents that can be read'). It distinguishes from the sibling tool 'read_doc_contents' by implying the listing is a precursor to reading, but does not explicitly differentiate.
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?
No guidance on when to use this tool versus alternatives. It is implied that listing is a discovery step before reading, but there are no explicit usage contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_doc_contentsA
Read the contents of a PDF document and return it as a string.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | PDF filename to read |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the tool reads PDFs and returns a string, but does not mention behavior for non-existent files, access permissions, large file handling, or any side effects. Adequate but minimal.
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?
One sentence, front-loaded with the action verb 'Read', zero wasted words. Every element serves a purpose.
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?
For a simple single-parameter tool with no output schema, the description is mostly adequate. It covers the core purpose and return type, but could benefit from mentioning error cases (file not found, unreadable) or that the string contains raw text from the PDF.
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 coverage is 100%, so the description adds little beyond the schema. It correctly describes the single parameter as a 'PDF filename', matching the schema's description. No additional meaning about format, path conventions, or restrictions is provided.
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 reads a PDF and returns its content as a string. It specifies both the file type (PDF) and the return format, distinguishing it from siblings like list_available_pdfs which lists files rather than reading them.
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 implies when to use this tool (after listing PDFs), but does not explicitly state when not to use it or mention alternatives. No guidance on prerequisite steps (e.g., file must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have clearly distinct purposes: one lists available PDFs, the other reads their contents. There is no overlap or ambiguity.
Both tools use snake_case and follow a verb_noun pattern (read_doc_contents, list_available_pdfs). The slight inconsistency between 'doc_contents' and 'pdfs' is minor, and overall naming is predictable.
With only 2 tools, the server is minimal. For a PDF extraction server, a few more tools (e.g., extract metadata, search text) would be expected, but the scope may be intentionally narrow.
The server lacks common operations like extracting specific pages, retrieving metadata, or searching within PDFs. The surface is incomplete for typical PDF extraction tasks.
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Generate PDFs from templates via AI chat. Works with Claude, ChatGPT, Cursor, and any MCP client.
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Claude to fetch, process, and extract information from PDF documents, including LaTeX mathematical equations.4MIT
- FlicenseAqualityNot gradedmaintenanceA Model Context Protocol server that extracts and processes content from PDF documents, providing text extraction, metadata retrieval, page-level processing, and PDF validation capabilities.41
- AlicenseAqualityCmaintenanceA 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.7291MIT
- AlicenseNot gradedqualityDmaintenanceA secure Model Context Protocol server that enables Claude AI to list, search, and read local documents in formats such as PDF, DOCX, and XLSX. It features read-only access with path traversal protection and supports deployment via Docker with SSE or STDIO transport options.MIT
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/einsteindark-edgm/mcp-read-doc-local'
If you have feedback or need assistance with the MCP directory API, please join our Discord server