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 Server search for 'conclusion' in research_paper.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.
A Model Context Protocol (MCP) server that provides efficient PDF text extraction capabilities for Claude Code. This server allows you to read, search, and extract metadata from PDF files without loading the entire content into Claude's context window.
npm package: @fabriqa.ai/pdf-reader-mcp Author: Cengiz Han Blog Post: How I Built This Tool to Save My Context
Read PDF Files: Extract full text content from PDF files with optional text cleaning
Search PDFs: Search for specific text within PDFs with context-aware results
Extract Metadata: Get detailed metadata including title, author, page count, dates, etc.
Efficient Context Usage: Process large PDFs without consuming excessive Claude Code context
Flexible Options: Support for page ranges, case-sensitive search, and more
Related MCP server: PDF MCP Server
npm install -g @fabriqa.ai/pdf-reader-mcpAfter installation, the server will be available globally. You can configure it by running:
# The package will be installed in your global node_modules
# Typically: /usr/local/lib/node_modules/@fabriqa.ai/pdf-reader-mcpClone this repository:
git clone https://github.com/hancengiz/read_pdf_as_text_mcp.git
cd read_pdf_as_text_mcpInstall dependencies:
npm install# Add the MCP server
claude mcp add pdf-reader npx @fabriqa.ai/pdf-reader-mcp@latest
# Or use the convenience script
npx @fabriqa.ai/pdf-reader-mcp/update-config.jsAdd to your ~/.claude.json:
{
"mcpServers": {
"pdf-reader": {
"command": "npx",
"args": [
"@fabriqa.ai/pdf-reader-mcp@latest"
]
}
}
}This uses npx to automatically run the globally installed package without needing to specify paths.
After installing via npm, you can use the included configuration script to automatically update your ~/.claude.json:
npx @fabriqa.ai/pdf-reader-mcp/update-config.jsOr if installed from source:
node update-config.jsThis will automatically add the MCP server using npx, making it available machine-wide across all your projects.
For Claude Desktop, edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"pdf-reader": {
"command": "npx",
"args": [
"@fabriqa.ai/pdf-reader-mcp@latest"
]
}
}
}Once configured, restart Claude Code. The following tools will be available:
Extract text content from a PDF file.
Parameters:
file (required): Path to the PDF file
pages (optional): Page range (e.g., '1-5', '1,3,5', 'all'). Default: 'all'
clean_text (optional): Clean and normalize extracted text. Default: false
include_metadata (optional): Include PDF metadata in output. Default: true
Example:
Can you read the PDF at /path/to/document.pdf?Search for specific text within a PDF file.
Parameters:
file (required): Path to the PDF file
query (required): Text to search for
case_sensitive (optional): Case sensitive search. Default: false
whole_word (optional): Match whole words only. Default: false
Example:
Search for "machine learning" in /path/to/document.pdfExtract metadata from a PDF file.
Parameters:
file (required): Path to the PDF file
Example:
Get metadata from /path/to/document.pdfHere's how you might use this MCP server with Claude Code:
Extract metadata first to understand the document:
What's the metadata for ~/Documents/research-paper.pdf?Search for specific topics without reading the entire file:
Search for "neural networks" in ~/Documents/research-paper.pdfRead specific sections when you know what you're looking for:
Read pages 10-15 from ~/Documents/research-paper.pdf with cleaned textContext Efficiency: Process large PDF files without loading everything into Claude's context
Faster Analysis: Search and extract only what you need
Better Performance: Reduce token usage when working with multiple or large PDFs
Flexible Extraction: Choose what information to extract and how to format it
Built with the @modelcontextprotocol/sdk
Uses pdf-parse for PDF text extraction
Runs as a local Node.js process communicating via stdio
Supports all PDF versions that pdf-parse can handle
Verify the path in your configuration file is correct
Ensure Node.js is installed and in your PATH
Check that dependencies are installed: npm install
Restart Claude Code completely
Check Claude Code logs for any error messages
Use absolute paths to PDF files
Verify file permissions
Ensure the PDF file exists at the specified location
Some PDFs (scanned images) may not contain extractable text
Try enabling clean_text option for better formatting
Complex layouts may affect text extraction quality
To modify or extend the server:
Edit index.js to add new tools or modify existing ones
Update the ListToolsRequestSchema handler to register new tools
Add corresponding handlers in the CallToolRequestSchema handler
Restart the server (restart Claude Code) to test changes
MIT
Created by Cengiz Han
Feel free to submit issues or pull requests to improve this MCP server.
Extract metadata from a PDF file including title, author, page count, creation date, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the PDF file to get metadata from |
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 states the tool extracts metadata but doesn't mention error handling (e.g., for invalid files), performance characteristics, or what happens if metadata fields are missing. For a tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence that front-loads the core purpose and provides examples of metadata fields. There is no wasted verbiage, and every word earns its place.
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 tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return values (since no output schema exists) and behavioral context, which are important for a tool performing extraction. It's complete enough for basic understanding but has clear gaps.
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 input schema has 100% description coverage, with the single parameter 'file' clearly documented as 'Path to the PDF file to get metadata from'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3.
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 with a specific verb ('Extract') and resource ('metadata from a PDF file'), and lists example metadata fields. It distinguishes from the 'read-pdf' sibling (likely for content extraction) and 'search-pdf' (likely for text search), though not explicitly. A 5 would require explicit sibling differentiation.
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 no guidance on when to use this tool versus the sibling tools 'read-pdf' or 'search-pdf'. It also lacks information about prerequisites (e.g., file accessibility) or alternative approaches. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract text from a PDF file. Returns the full text content of the PDF with optional page filtering and text cleaning.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the PDF file to extract text from | |
| pages | No | Page range (e.g., '1-5', '1,3,5', 'all'). Default: 'all' | |
| clean_text | No | Clean and normalize extracted text. Default: false | |
| include_metadata | No | Include PDF metadata in output. Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior by stating it 'returns the full text content' and mentions optional features like page filtering and text cleaning. However, it lacks details on error handling, performance characteristics, or limitations (e.g., file size constraints, supported PDF formats), which would be valuable for an agent.
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 two sentences, front-loaded with the core purpose ('Extract text from a PDF file') followed by additional context about return values and optional features. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized.
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 tool's moderate complexity (4 parameters, no output schema, no annotations), the description is reasonably complete. It covers the main purpose and key behavioral aspects (returning text, optional features). However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the text output, handling of metadata), slightly reducing 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 input schema has 100% description coverage, providing clear documentation for all 4 parameters. The description adds minimal value beyond the schema by mentioning 'optional page filtering and text cleaning', which loosely corresponds to the 'pages' and 'clean_text' parameters but does not provide additional semantic context. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Extract text from a PDF file') and resource ('PDF file'), distinguishing it from sibling tools like 'pdf-metadata' (which likely extracts metadata) and 'search-pdf' (which likely searches within PDFs). The verb 'extract text' precisely defines the tool's function.
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 usage for text extraction from PDFs but does not explicitly state when to use this tool versus alternatives like 'pdf-metadata' or 'search-pdf'. It mentions optional features (page filtering, text cleaning) which provide some context, but lacks explicit guidance on tool selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific text within a PDF file. Returns matching text with context and page numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the PDF file to search in | |
| query | Yes | Text to search for | |
| case_sensitive | No | Case sensitive search. Default: false | |
| whole_word | No | Match whole words only. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format ('Returns matching text with context and page numbers'), which is valuable behavioral information. However, it doesn't mention potential limitations like maximum file size, search performance, error conditions, or authentication requirements that would help an agent understand operational constraints.
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 perfectly concise with two sentences that each earn their place: the first states the purpose, the second specifies the return format. No wasted words, front-loaded with core functionality, and appropriately sized for the tool's complexity.
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 tool's moderate complexity (4 parameters, search operation), no annotations, and no output schema, the description provides good coverage of what the tool does and what it returns. However, it lacks details about error handling, performance characteristics, or limitations that would make it fully complete for agent decision-making.
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 four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but provides no additional semantic context.
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 specific action ('Search for specific text'), target resource ('within a PDF file'), and distinguishes from siblings by focusing on text search rather than metadata extraction (pdf-metadata) or full content reading (read-pdf). It provides a complete purpose statement with verb+resource+differentiation.
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 usage context (searching within PDFs) but doesn't explicitly state when to use this tool versus alternatives like read-pdf for full content or pdf-metadata for file information. No explicit when-not-to-use guidance or named alternatives are provided, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.7pdf-metadataread-pdfsearch-pdfEach tool has a clearly distinct purpose: pdf-metadata extracts document properties, read-pdf extracts all text content, and search-pdf finds specific text within the document. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb-noun pattern using hyphens (pdf-metadata, read-pdf, search-pdf). The naming is predictable and readable, with 'pdf' consistently placed as a suffix or prefix across all tools.
Three tools is a minimal but reasonable count for a PDF reader server, covering core operations: metadata extraction, full text reading, and text search. It could benefit from additional tools like PDF conversion or annotation handling, but it's well-scoped for basic use.
The toolset covers essential PDF reading operations: metadata, full text extraction, and search. Minor gaps exist, such as no tools for PDF manipulation (e.g., merging, splitting) or advanced features like OCR, but agents can perform basic workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Parse, extract, split, and ask over digital PDFs (text layer, no OCR) from Cursor and Claude.
Generate and read PDFs for AI agents: a generate_pdf and a read_pdf tool, priced per document.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Read PDFs and images as markdown or text, with exact costs and hard spend caps. $0.75/1k pages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hancengiz/read_pdf_as_text_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
