What can you do with this server?

The MCP PDF Reader server enables AI assistants to extract, search, and analyze content from PDF documents through the Model Context Protocol (MCP). Core Capabilities: * Extract full text content from entire PDFs with optional metadata inclusion * Read specific pages or page ranges for targeted content extraction * Retrieve document metadata including title, author, creation/modification dates, keywords, and page count * Search for text within PDFs with case-sensitive/insensitive options, returning matches with surrounding context * Get page count to quickly determine document size * List embedded images with metadata (page location, dimensions, type, name, index) * Extract individual images as Base64-encoded data for processing or saving * Integrate with AI assistants like Claude Desktop and GitHub Copilot * Test functionality using the MCP Inspector for debugging and validation Limitations: * ⚠️ No OCR support - only works with text-based PDFs containing selectable/embedded text (not scanned documents) * ⚠️ Read-only - cannot edit, create, or modify PDF files * ⚠️ Standard image formats only - supports JPEG, PNG, and TIFF extraction

Which integrations are available for this server?

Enables GitHub Copilot to analyze PDF files through standardized tools for searching content, reading specific page ranges, and extracting embedded visual assets.

How do I use MCP PDF Reader?

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., "@MCP PDF Reader summarize pages 1 to 3 of C:/Users/Documents/contract.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.

MCP PDF Reader

by rturv

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP PDF Reader

Available Languages: 🇬🇧 English | 🇪🇸 Español

A powerful Model Context Protocol (MCP) server that empowers AI assistants like Claude and GitHub Copilot to intelligently interact with PDF documents. Extract text, metadata, search content, and retrieve embedded images—all through a standardized, LLM-friendly interface. Not OCR-based.

Current Version: 1.0.0
Package: @rturv/mcp-pdf-reader
License: MIT

Quick Start

Installation

npm install -g @rturv/mcp-pdf-reader

Run the Server

mcp-pdf-reader

Related MCP server: MCP PDF Reader

Configuration

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "pdf-reader": {
      "command": "mcp-pdf-reader"
    }
  }
}

Location:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json

GitHub Copilot (VS Code)

Add to mcpServers.json:

{
  "mcpServers": {
    "pdf-reader": {
      "command": "mcp-pdf-reader",
      "args": [],
      "disabled": false
    }
  }
}

Location: %APPDATA%\Code\User\globalStorage\github.copilot-chat\mcpServers.json

See COPILOT_CONFIG.md for additional installation methods.

Features

✅ Full Text Extraction - Extract complete text from PDF files
✅ Metadata Extraction - Retrieve title, author, creation date, and more
✅ Page Range Reading - Extract text from specific pages
✅ Text Search - Find text with surrounding context
✅ Page Count - Get total page count
✅ Image Extraction - List and extract embedded images in Base64
✅ Standards Compliant - Follows MCP specification for seamless LLM integration

Tools Reference

This MCP server exposes 7 tools for comprehensive PDF manipulation. All tools are accessible through Claude Desktop, GitHub Copilot, and other MCP-compatible clients.

1. `read_pdf`

Purpose: Extract all text content from a PDF file. Use this as your primary method for understanding PDF document content.

When to use:

Reading entire document content
Getting full document text for summarization or analysis
Extracting content when combined with metadata

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file",
  "includeMetadata": "boolean (optional, default: false) - Include PDF metadata in response"
}

Example Request:

{
  "filePath": "C:/Documents/report.pdf",
  "includeMetadata": true
}

Example Response:

{
  "text": "Executive Summary\n\nThis report details Q4 2025 performance...",
  "metadata": {
    "title": "Q4 2025 Performance Report",
    "author": "Analytics Team",
    "subject": "Quarterly Report",
    "creator": "Microsoft Word",
    "producer": "iLovePDF",
    "creationDate": "D:20250115120000Z",
    "modificationDate": "D:20250115150000Z",
    "keywords": "Q4, report, performance",
    "totalPages": 12
  },
  "pageCount": 12
}

2. `get_pdf_metadata`

Purpose: Extract document metadata without reading the full text. Ideal for quick document inspection.

When to use:

Identifying document properties (author, title, dates)
Quick document validation
Building document catalogs
Checking modification dates

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file"
}

Example Request:

{
  "filePath": "C:/Documents/contract.pdf"
}

Example Response:

{
  "title": "Service Agreement 2025",
  "author": "Legal Department",
  "subject": "Service Terms & Conditions",
  "creator": "Adobe InDesign",
  "producer": "Adobe PDF Library",
  "creationDate": "D:20250101090000Z",
  "modificationDate": "D:20250110140000Z",
  "keywords": "service, agreement, contract",
  "totalPages": 8
}

3. `read_pdf_pages`

Purpose: Extract text from a specific page or range of pages. Use this for targeted content extraction.

When to use:

Reading specific sections of a document
Analyzing particular chapters or pages
Extracting cover pages or specific reports within a multi-part document
Handling large PDFs by reading sections

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file",
  "startPage": "number (required) - Starting page number (1-indexed)",
  "endPage": "number (optional) - Ending page number. If omitted, defaults to startPage"
}

Example Request (single page):

{
  "filePath": "C:/Documents/thesis.pdf",
  "startPage": 1
}

Example Request (page range):

{
  "filePath": "C:/Documents/thesis.pdf",
  "startPage": 5,
  "endPage": 12
}

Example Response:

{
  "text": "Chapter 2: Literature Review\n\nThis chapter examines existing research...",
  "startPage": 5,
  "endPage": 12,
  "totalPages": 45
}

4. `search_pdf`

Purpose: Search for text within a PDF and retrieve all matches with surrounding context.

When to use:

Finding specific terms or phrases
Locating sections by keyword
Validating content presence
Building keyword-based summaries
Compliance checking (finding specific clauses)

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file",
  "searchTerm": "string (required) - Text to search for",
  "caseSensitive": "boolean (optional, default: false) - Case-sensitive search"
}

Example Request:

{
  "filePath": "C:/Documents/policy.pdf",
  "searchTerm": "termination clause",
  "caseSensitive": false
}

Example Response:

[
  {
    "page": 3,
    "text": "termination clause",
    "context": "...either party may invoke the termination clause without prior written notice...",
    "position": 456
  },
  {
    "page": 7,
    "text": "termination clause",
    "context": "...In accordance with Section 4.2, the termination clause becomes effective...",
    "position": 1230
  }
]

5. `get_pdf_page_count`

Purpose: Get the total number of pages in a PDF without reading content.

When to use:

Validating PDF integrity
Determining if a PDF is empty
Planning page range extractions
Batch processing logic based on document size

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file"
}

Example Request:

{
  "filePath": "C:/Documents/manual.pdf"
}

Example Response:

{
  "pageCount": 247
}

6. `list_pdf_images`

Purpose: List all images embedded in a PDF with their metadata and locations.

When to use:

Discovering embedded images before extraction
Getting image dimensions and types
Planning image extraction operations
Validating image content presence

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file"
}

Example Request:

{
  "filePath": "C:/Documents/presentation.pdf"
}

Example Response:

{
  "images": [
    {
      "index": 0,
      "page": 2,
      "name": "Image42",
      "width": 800,
      "height": 600,
      "type": "JPEG"
    },
    {
      "index": 1,
      "page": 5,
      "name": "Image43",
      "width": 1024,
      "height": 768,
      "type": "PNG"
    },
    {
      "index": 2,
      "page": 8,
      "name": "Image44",
      "width": 640,
      "height": 480,
      "type": "TIFF"
    }
  ]
}

7. `extract_pdf_image`

Purpose: Extract a specific image from a PDF and return it as Base64-encoded data.

When to use:

Recovering images from PDFs
Converting PDF images to standard formats
Processing visual content for analysis
Archiving embedded images

Before using: Call list_pdf_images first to discover available images and their indices.

Input Parameters:

{
  "filePath": "string (required) - Absolute path to the PDF file",
  "imageIndex": "number (required) - Image index from list_pdf_images (0-indexed)"
}

Example Request:

{
  "filePath": "C:/Documents/presentation.pdf",
  "imageIndex": 0
}

Example Response:

{
  "index": 0,
  "page": 2,
  "name": "Image42",
  "width": 800,
  "height": 600,
  "type": "JPEG",
  "data": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg=="
}

Note: Image data is Base64 encoded. Decode it to save as a file (e.g., using atob() in JavaScript or base64 -d in bash).

Testing with MCP Inspector

The MCP Inspector is an interactive tool for testing and debugging MCP servers. It provides a web-based UI to invoke tools and inspect responses in real-time.

Installation

npm install -g @modelcontextprotocol/inspector

Running the Server with Inspector

Start the MCP server in debug mode:
```
mcp-pdf-reader
```
In a separate terminal, launch the Inspector:
```
mcp-inspector node dist/index.js
```
Or if using the global npm package:
```
mcp-inspector npx @rturv/mcp-pdf-reader
```
Open the web UI: The Inspector will provide a URL (typically http://localhost:5173). Open it in your browser.

Using the Inspector

Example: Extract text from a PDF

In the Inspector UI, find the read_pdf tool in the left sidebar
Click on it to expand the tool interface

Enter the parameters:

{
  "filePath": "C:/path/to/your/document.pdf",
  "includeMetadata": true
}

Click "Call Tool"
View the response in the right panel

Example: Search for text

Select the search_pdf tool

Enter parameters:

{
  "filePath": "C:/path/to/your/document.pdf",
  "searchTerm": "important keyword",
  "caseSensitive": false
}

Click "Call Tool" and review the search results with context

Example: Extract an image

First, call list_pdf_images to discover images:

{
  "filePath": "C:/path/to/your/document.pdf"
}

Note the index of the image you want (e.g., index: 0)

Call extract_pdf_image with that index:

{
  "filePath": "C:/path/to/your/document.pdf",
  "imageIndex": 0
}

The response will include Base64-encoded image data ready for decoding and saving

Troubleshooting Inspector Issues

Port already in use: Change the port with mcp-inspector --port 5174
Connection refused: Ensure the MCP server is running before starting the Inspector
Tool not appearing: Verify the tool definition in src/index.ts and rebuild with npm run build

Development

Build

npm run build

Watch Mode

npm run dev

Run Tests

npm test

Note: Tests require a sample PDF at test-files/sample.pdf. Create one or skip PDF-dependent tests.

Watch Tests

npm run test:watch

Project Structure

mcp-pdf-reader/
├── src/
│   ├── index.ts              # MCP server implementation & tool definitions
│   ├── pdf-tools.ts          # Core PDF manipulation functions
│   ├── types.ts              # TypeScript interfaces & types
│   └── __tests__/
│       └── pdf-tools.test.ts  # Unit tests
├── dist/                      # Compiled JavaScript (generated)
├── test-files/                # Test PDF files
├── package.json
├── tsconfig.json
└── README.md

Technology Stack

@modelcontextprotocol/sdk (^1.25.2) - MCP protocol implementation
pdf-parse (^2.4.5) - PDF text extraction
pdf-lib (^1.17.1) - PDF image extraction
TypeScript (^5.9.3) - Type-safe development
Jest (^29.7.0) - Unit testing

Limitations

No OCR: Only extracts selectable text from PDFs (not scanned images)
Text-based PDFs: Works best with PDFs containing embedded text. Scanned documents without OCR cannot be read
Image extraction: Standard formats only (JPEG, PNG, TIFF)
Base64 encoding: All images are returned as Base64 strings; large images may result in large responses
No PDF modification: This server is read-only; it cannot edit or create PDFs

Configuration Files

CLAUDE_CONFIG.md - Claude Desktop configuration guide
COPILOT_CONFIG.md - GitHub Copilot setup instructions

License

MIT - See LICENSE file for details

Repository

github.com/rturv/mcp-pdf-reader

Available Tools

7 tools

extract_pdf_imageA

Extract a specific image from a PDF by its index (use list_pdf_images to get available indices)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Absolute path to the PDF file
`imageIndex`	Yes	Index of the image to extract (0-based, from list_pdf_images)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided; description omits behavioral details like error handling (e.g., out-of-range index) or output format, placing full burden on a sparse description.

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?

Single, front-loaded sentence with no extraneous content; every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output format details and error behavior; though simple, missing information for a tool with no output schema or annotations.

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 clear parameter descriptions; the tool description adds minimal extra value beyond restating schema info, achieving baseline.

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?

Clearly states it extracts a specific image from a PDF by index, distinguishing from siblings like list_pdf_images which is referenced as prerequisite.

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?

Explicitly advises using list_pdf_images first to obtain indices, providing clear usage guidance, though not specifying when not to use.

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

get_pdf_metadataB

Extract metadata information from a PDF file (title, author, creation date, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Absolute path to the PDF file

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose safety properties (e.g., read-only nature), error handling for missing files, or permissions required. The description carries the full behavioral disclosure burden but provides only a high-level summary.

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 a single concise sentence that front-loads the core action ('Extract metadata information'). Every word carries meaning with no fluff or redundancy, earning a top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple metadata extraction tool but lacks details on return format (no output schema) and does not address limitations or variations. It covers the basic purpose but leaves some gaps for an AI agent.

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% since 'filePath' is fully described in the input schema. The description adds no additional parameter-level context beyond what the schema already provides. Baseline score of 3 applies, as the description does not reduce clarity.

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 'Extract metadata information from a PDF file' with specific metadata fields listed (title, author, creation date). This verb+resource combination is distinct from sibling tools like 'extract_pdf_image' or 'read_pdf', making the tool's purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 its siblings (e.g., get_pdf_page_count, search_pdf). An agent would not know that this tool is for metadata only, not content or images, without additional context.

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

get_pdf_page_countC

Get the total number of pages in a PDF file

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Absolute path to the PDF file

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must cover behavior. It only states the purpose without disclosing error handling, return format, performance characteristics, or file access assumptions.

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?

Single sentence, no filler, front-loaded with key action. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is too sparse. It lacks return type, error cases, and usage examples, leaving the agent with minimal actionable detail.

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 a single parameter well-described in the schema. The description does not add new semantics beyond repeating 'PDF file', so baseline score fits.

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 verb 'get' and resource 'total number of pages in a PDF file', distinguishing it from siblings like get_pdf_metadata or read_pdf.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as read_pdf_pages or search_pdf. No context about prerequisites or typical use cases.

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

list_pdf_imagesA

List all images embedded in a PDF file with their metadata (page, dimensions, type)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Absolute path to the PDF file

TDQS

A4.1/5.0

Behavior4/5

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

The description clearly states the tool lists images with metadata, which implies a read-only operation. No annotations are present, so the description carries full burden; it adequately conveys behavior without contradicting any 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 a single, concise, and front-loaded sentence with no unnecessary words. Every word adds value.

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 has one required parameter and no output schema, the description fully covers what the tool does and what it returns. It is complete for the complexity level.

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 describes 'filePath' as an absolute path to the PDF file. The description adds no additional meaning beyond the schema, so baseline score applies due to high schema 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 lists all images embedded in a PDF and specifies the metadata returned (page, dimensions, type). It uses a specific verb and resource, and implicitly distinguishes from siblings like 'extract_pdf_image'.

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 implies usage for obtaining image information from a PDF, but does not explicitly state when to use it vs alternatives like 'extract_pdf_image' or 'get_pdf_metadata'. No 'when-not' guidance is provided.

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

read_pdfB

Extract all text content from a PDF file

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Absolute path to the PDF file
`includeMetadata`	No	Whether to include PDF metadata in the response

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry behavioral disclosure. It only states 'extract', implying a read operation, but does not mention potential pitfalls (e.g., large files, access rights) or that it reads the entire file.

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 a single, front-loaded sentence without any superfluous information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description omits crucial context like return format, error handling, behavior with large files, or whether metadata can be included. Two parameters are documented but the tool's overall behavior is underspecified.

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?

Input schema has 100% coverage with clear descriptions for both parameters. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.

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 'Extract all text content from a PDF file' clearly states the verb (extract), resource (PDF text), and scope (all), distinguishing it from sibling tools like extract_pdf_image or get_pdf_metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like read_pdf_pages or search_pdf. The description lacks when-not scenarios or alternative suggestions.

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

read_pdf_pagesB

Extract text from specific pages or page range in a PDF

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Absolute path to the PDF file
`startPage`	Yes	Starting page number (1-indexed)
`endPage`	No	Ending page number (optional, defaults to startPage)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description does not disclose how invalid page numbers are handled, whether images are excluded, or any side effects. Minimal behavioral 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?

Single, clear sentence that is front-loaded and concise. Could be slightly expanded for context but adequate for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or description of return format. Does not explain error handling or boundary conditions for pages. Incomplete for a tool with 3 parameters.

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%, so parameters are described in the schema. The description adds no extra meaning beyond the schema, meeting baseline.

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?

Description clearly states the action (extract text) and scope (specific pages or page range). It distinguishes from sibling 'read_pdf' which likely reads entire PDF.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs alternatives like 'read_pdf' or 'search_pdf'. No mention of limitations or prerequisites.

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

search_pdfB

Search for text in a PDF and return all matches with context

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Absolute path to the PDF file
`searchTerm`	Yes	Text to search for in the PDF
`caseSensitive`	No	Whether the search should be case sensitive

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose whether the tool is read-only, requires specific file permissions, or any error behaviors. The read-only nature is implied but not confirmed.

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 a single sentence of 10 words, efficiently conveying the core function. However, it sacrifices clarity for brevity, particularly around the return format ('context').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description should explain the return value structure (e.g., list of matches with page numbers and surrounding text). The vague phrase 'context' does not sufficiently inform the agent.

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 three parameters are well-described in the input schema with clear descriptions, achieving 100% schema coverage. The tool description adds no additional semantic value beyond the schema.

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 searches for text in a PDF and returns matches with context. It distinguishes from sibling tools like extract_pdf_image or get_pdf_metadata by focusing on text search, but lacks detail on what 'context' entails.

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 implies use when finding text occurrences in a PDF, but does not explicitly compare with alternatives like read_pdf for full content extraction. No when-not-to-use guidance or prerequisites are given.

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

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct aspect of PDF handling: reading text, reading specific pages, searching, metadata, page count, and image extraction. No two tools overlap in purpose, making selection unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., read_pdf, search_pdf, list_pdf_images). Naming is predictable and clear.

Tool Count5/5

With 7 tools covering the core operations of a PDF reader (read, search, metadata, images), the set is well-scoped. Each tool earns its place without redundancy or excess.

Completeness5/5

The tool surface covers all essential PDF reading operations: full text extraction, page-specific extraction, search, metadata retrieval, page count, and image handling. No critical gaps for the intended use case.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
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
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 COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
2

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 Multimedia Processing
3351163616
F
license
D
quality
D
maintenance
Intelligent PDF processing server that automatically detects PDF types (text or scanned), extracts text, performs OCR recognition in 10 languages, searches content with regex support, and retrieves metadata through the Model Context Protocol.
Updated 10 months ago (2025-11-05 06:58 UTC)
7
3
PDF Reader MCP
File Systems Documentation Access Developer Tools
BACH-AI-Tools
A
license
Not graded
quality
D
maintenance
A high-performance Model Context Protocol server that enables AI agents to extract text, images, and metadata from PDF documents using parallel processing. It features intelligent Y-coordinate content ordering to preserve natural reading flow and supports both local files and URL-based sources.
Updated 7 months ago (2026-02-16 15:56 UTC)
14
MIT
pdf-mcp
RAG Systems Search Documentation Access
jztan
A
license
A
quality
A
maintenance
A Model Context Protocol server that enables AI agents to read, search, and extract content from PDF files.
Updated 16 hours ago (2026-09-03 11:24 UTC)
13
130
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/rturv/mcp-pdf-reader'

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

MCP PDF Reader

Quick Start

Installation

Run the Server

Configuration

Claude Desktop

GitHub Copilot (VS Code)

Features

Tools Reference

1. read_pdf

2. get_pdf_metadata

3. read_pdf_pages

4. search_pdf

5. get_pdf_page_count

6. list_pdf_images

7. extract_pdf_image

Testing with MCP Inspector

Installation

Running the Server with Inspector

Using the Inspector

Example: Extract text from a PDF

Example: Search for text

Example: Extract an image

Troubleshooting Inspector Issues

Development

Build

Watch Mode

Run Tests

Watch Tests

Project Structure

Technology Stack

Limitations

Configuration Files

License

Repository

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `read_pdf`

2. `get_pdf_metadata`

3. `read_pdf_pages`

4. `search_pdf`

5. `get_pdf_page_count`

6. `list_pdf_images`

7. `extract_pdf_image`