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 MCP extract text from 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.
MCP server for PDF processing and analysis using PyPDFium2.
extract_text: Extract text content from PDF files with page range support
extract_metadata: Extract PDF metadata including title, author, and page count
search_text: Search for specific text within PDF files with context
get_page_count: Get the total number of pages in a PDF file
extract_pages: Extract specific pages from a PDF and save as a new PDF
split_pdf: Split a PDF into multiple page-based PDFs with base64 encoding
merge_pdfs: Merge multiple PDF files into a single PDF
pdf_to_images: Convert PDF pages to PNG images with configurable DPI
get_form_fields: Extract all form fields from a PDF including names, types, and values
fill_form: Fill form fields in a PDF with provided values and save to output path
Related MCP server: PDF Manipulation MCP Server
# Clone the repository
git clone https://github.com/gzigurella/pdf-mcp.git
cd pdf-mcp
# Create virtual environment
python3 -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install the package
pip install -e .# Clone and enter directory
git clone https://github.com/gzigurella/pdf-mcp.git
cd pdf-mcp
# Install with uv
uv pip install -e .Add to your ~/.config/opencode/opencode.json:
{
"mcpServers": {
"pdf-mcp": {
"type": "local",
"command": [
"/path/to/pdf-mcp/venv/bin/python",
"-m",
"pdf_mcp"
],
"enabled": true
}
}
}Add to your Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"pdf-mcp": {
"command": "/path/to/pdf-mcp/venv/bin/python",
"args": ["-m", "pdf_mcp"]
}
}
}For any MCP-compatible client:
# Start the server directly
/path/to/venv/bin/python -m pdf_mcpThe server communicates via stdio using the MCP protocol.
Extract text content from a PDF file. Supports PDFs with searchable text and can extract text from specific pages or ranges.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to extract text from |
pages | string | No | "all" | Page range to extract (e.g., '1-5', '3,7,9', 'all') |
{
"file_path": "/path/to/document.pdf",
"pages": "1-5"
}Extract metadata from a PDF file including title, author, subject, keywords, creator, producer, creation date, modification date, and page count.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to extract metadata from |
{
"file_path": "/path/to/document.pdf"
}Search for specific text within a PDF file. Returns page numbers and context around the found text. Useful for finding specific content in large documents.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to search within |
query | string | Yes | - | Text to search for in the PDF |
case_sensitive | boolean | No | false | Whether to perform case-sensitive search |
context_words | integer | No | 10 | Number of words to include before and after each match |
{
"file_path": "/path/to/document.pdf",
"query": "important term",
"case_sensitive": false,
"context_words": 5
}Get the total number of pages in a PDF file. Returns a simple integer count.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to count pages for |
{
"file_path": "/path/to/document.pdf"
}Extract specific pages from a PDF file and save as a new PDF. Supports page ranges and individual page selection.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the source PDF file |
pages | string | Yes | - | Pages to extract (e.g., '1-5', '3,7,9', '1,3-5') |
output_path | string | Yes | - | Path where the extracted pages will be saved as a new PDF |
{
"file_path": "/path/to/source.pdf",
"pages": "1,3,5-7",
"output_path": "/path/to/output.pdf"
}Split a PDF file into multiple separate PDF files based on page ranges. Returns a JSON with base64-encoded PDFs for each selected page. Supports single pages, page ranges, and all pages.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to split |
page_range | string | Yes | - | Page range to split - 'all', single page (e.g., '1'), or range (e.g., '1-3', '2-5') |
{
"file_path": "/path/to/document.pdf",
"page_range": "1-3"
}Merge multiple PDF files into a single PDF. Files are merged in the order provided.
Parameter | Type | Required | Default | Description |
file_paths | array | Yes | - | List of PDF file paths to merge |
output_path | string | Yes | - | Path where the merged PDF will be saved |
{
"file_paths": ["/path/to/doc1.pdf", "/path/to/doc2.pdf", "/path/to/doc3.pdf"],
"output_path": "/path/to/merged.pdf"
}Convert PDF pages to PNG images. Returns a JSON with base64-encoded PNG images for each page. Supports custom DPI settings for resolution control.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to convert to images |
dpi | integer | No | 150 | Image resolution in dots per inch |
format | string | No | "png" | Image format (PNG only) |
{
"file_path": "/path/to/document.pdf",
"dpi": 300,
"format": "png"
}Extract all form fields from a PDF document including field names, types, current values, and available choices for dropdown fields.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the PDF file to extract form fields from |
{
"file_path": "/path/to/form.pdf"
}Returns a JSON with field information:
{
"fields": [
{
"name": "first_name",
"type": "text",
"value": "",
"page": 1,
"rect": {"x0": 50, "y0": 72, "x1": 150, "y1": 92}
},
{
"name": "country",
"type": "combobox",
"value": "",
"page": 1,
"rect": {...},
"choices": ["USA", "Canada", "UK"]
},
{
"name": "accept_terms",
"type": "checkbox",
"value": "",
"page": 1,
"rect": {...},
"on_state": "Yes"
}
],
"total_fields": 3
}Fill form fields in a PDF document with provided values and save to output path. Supports text fields, checkboxes, radio buttons, and dropdowns.
Parameter | Type | Required | Default | Description |
file_path | string | Yes | - | Path to the source PDF file |
fields | object | Yes | - | Dictionary of field names and their values to fill |
output_path | string | Yes | - | Path where the filled PDF will be saved |
{
"file_path": "/path/to/form.pdf",
"fields": {
"first_name": "John",
"last_name": "Doe",
"country": "USA",
"accept_terms": true
},
"output_path": "/path/to/filled_form.pdf"
}Checkbox values accept: true/false, "yes"/"no", "1"/"0".
Radio buttons: use the value from on_state field (get with get_form_fields first).
Variable | Default | Description |
PDF_MCP_DEBUG | false | Enable debug logging |
# Example
export PDF_MCP_DEBUG=true
python -m pdf_mcpsource venv/bin/activate
pytest
# With coverage
pytest --cov=src --cov-report=htmlpdf-mcp/
├── src/pdf_mcp/
│ ├── __init__.py
│ ├── __main__.py
│ ├── server.py
│ ├── config.py
│ └── tools/
│ ├── __init__.py
│ ├── extract_text.py
│ ├── extract_metadata.py
│ ├── search_text.py
│ ├── get_page_count.py
│ ├── extract_pages.py
│ ├── split_pdf.py
│ ├── merge_pdfs.py
│ ├── pdf_to_images.py
│ ├── get_form_fields.py
│ └── fill_form.py
├── tests/
├── pyproject.toml
└── README.mdIf you encounter installation errors, ensure you have Python 3.10 or later:
python --versionMake sure the PDF file paths are correct and the files exist:
ls -l /path/to/your/document.pdfThe tools will raise a RuntimeError if attempting to process encrypted PDFs. Ensure your PDFs are not password-protected.
For very large PDF files, consider processing them in smaller chunks using the extract_pages or split_pdf tools.
If you encounter permission errors, ensure the PDF files are readable:
chmod +r /path/to/your/document.pdfFile Access: The server only processes files that exist and are readable by the running process
Path Validation: All file paths are validated before processing
No Network Access: The server does not make any network requests
Temporary Files: Temporary files are properly cleaned up after processing
Error Handling: Sensitive information is not exposed in error messages
Encrypted PDFs: Password-protected PDFs are rejected with appropriate error messages
{
"name": "extract_text",
"arguments": {
"file_path": "/documents/report.pdf",
"pages": "1-3,7,9"
}
}{
"name": "search_text",
"arguments": {
"file_path": "/documents/contract.pdf",
"query": "liability clause",
"case_sensitive": true,
"context_words": 15
}
}{
"name": "merge_pdfs",
"arguments": {
"file_paths": [
"/reports/q1.pdf",
"/reports/q2.pdf",
"/reports/q3.pdf",
"/reports/q4.pdf"
],
"output_path": "/reports/annual.pdf"
}
}{
"name": "pdf_to_images",
"arguments": {
"file_path": "/documents/presentation.pdf",
"dpi": 300
}
}MIT
Extract metadata from a PDF file including title, author, subject, keywords, creator, producer, creation date, modification date, and page count.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the PDF file to extract metadata from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation by 'extract', but does not explicitly state non-destructiveness or any required permissions. Some behavioral transparency is present but incomplete.
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 sentence of 25 words, front-loaded with the main action and resource, containing no fluff.
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 no output schema, the description compensates by listing all metadata fields. However, it lacks details on return format, error handling, or file existence cases. Still fairly complete for a simple extraction tool.
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% with clear parameter docs. The description adds value beyond the schema by listing the metadata fields returned, helping the agent understand the output.
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 verb 'extract' and resource 'metadata from a PDF file', listing specific fields like title, author, subject, etc. It distinguishes the tool from siblings such as extract_text and extract_pages.
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 is provided on when to use this tool versus alternatives like extract_text or search_text. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract specific pages from a PDF file and save as a new PDF. Supports page ranges and individual page selection.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | Yes | Pages to extract (e.g., '1-5', '3,7,9', '1,3-5') | |
| file_path | Yes | Path to the source PDF file | |
| output_path | Yes | Path where the extracted pages will be saved as a new PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses basic behavior (saves new PDF) but lacks details on permissions, size limits, or error handling for out-of-range pages.
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?
Two concise sentences, no fluff, front-loaded 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?
Adequate for a simple tool with no output schema or annotations; could mention error behavior.
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 has 100% coverage with descriptions; description adds minimal value ('Supports page ranges...') beyond schema.
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?
Clear verb+resource: 'Extract specific pages from a PDF file and save as a new PDF.' Distinguishes from siblings like extract_text or pdf_to_images.
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?
Description implies usage context (extracting pages as PDF), but no explicit when-to-use or when-not-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract text content from a PDF file. Supports PDFs with searchable text and can extract text from specific pages or ranges. Returns plain text content.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | Page range to extract (e.g., '1-5', '3,7,9', 'all'). Default: all pages | |
| file_path | Yes | Path to the PDF file to extract text from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It notes the requirement for searchable text and output format, but lacks details on permissions, error handling, or performance characteristics.
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?
Three sentences with front-loaded purpose, each sentence adds meaningful detail without redundancy. No fluff.
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 no output schema, the description adequately states return type (plain text). It covers main use cases but omits details like character encoding or formatting preservation. Considering complexity and sibling set, fairly complete.
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 minimal value beyond the schema's parameter descriptions. It confirms the page range feature but does not introduce new semantic information.
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 (extract text), the resource (PDF file), and specifies capabilities (searchable text, page ranges) and output format (plain text). It distinguishes from siblings like extract_metadata and extract_pages.
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?
While it mentions support for PDFs with searchable text (implying limitation), it does not explicitly state when not to use it or suggest alternatives for scanned PDFs. No direct comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill form fields in a PDF document with provided values and save to output path. Supports text fields, checkboxes, radio buttons, and dropdowns.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Dictionary of field names and their values to fill | |
| file_path | Yes | Path to the source PDF file | |
| output_path | Yes | Path where the filled PDF will be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions supported field types (text, checkboxes, etc.) but does not disclose behavior like overwriting existing values, handling missing fields, or required permissions.
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?
Two concise sentences with no redundant information. The first sentence states the core action, the second adds supported field types. Efficient and front-loaded.
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?
While the tool is straightforward, the description lacks information about return value (e.g., success/error), and with nested object parameters (fields), more guidance on format would improve 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?
Schema coverage is 100%, so baseline is 3. The description adds value by listing supported field types (text, checkboxes, radio buttons, dropdowns), which enhances understanding beyond the schema's generic property descriptions.
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 fills form fields in a PDF and saves to an output path, using a specific verb and resource. It distinguishes from siblings like get_form_fields (which reads) and extract_text (extracts text).
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 filling PDF forms but provides no explicit guidance on when to use versus alternatives, nor does it mention prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all form fields from a PDF document including field names, types, current values, and available choices for dropdown fields.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the PDF file to extract form fields from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the extraction behavior and data types, but omits error handling, performance, or what happens with non-form PDFs.
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?
Single sentence, no redundancy, efficiently communicates purpose and output contents.
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?
Despite no output schema or annotations, the description adequately details the return structure (field names, types, values, choices) for a simple extraction tool; minor gap in absence of error conditions.
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% with one parameter having a description; the description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 extracts all form fields from a PDF and lists specific data included (names, types, values, choices), distinguishing it from siblings like extract_text and extract_metadata.
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 (for PDF form fields) but offers no explicit guidance on when not to use or alternatives; siblings like fill_form hint at context but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of pages in a PDF file. Returns a simple integer count.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the PDF file to count pages for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return type as integer count. No annotations, so description carries burden. Lacks details about file existence requirements or permission needs, but for a simple read operation it is adequate.
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?
Two sentences, no waste. Front-loaded with purpose and return type. Highly concise.
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 single-parameter tool with no output schema, description fully explains purpose and output. No missing information for expected use.
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 covers parameter file_path with description. Description does not add extra meaning beyond schema. Baseline 3 applies since schema coverage is 100%.
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?
Description uses specific verb 'Get' and resource 'number of pages in a PDF file', clearly distinguishing from siblings like extract_metadata or extract_text.
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?
Implied usage for counting pages, but no explicit when-to-use or when-not-to-use. Siblings provide alternatives but description does not mention them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge multiple PDF files into a single PDF. Returns a base64-encoded merged PDF. Files are merged in the order provided.
| Name | Required | Description | Default |
|---|---|---|---|
| file_paths | Yes | List of PDF file paths to merge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool merges PDFs, returns base64, and uses order provided. However, it omits details like whether original files are modified, error handling, or file size limits. Transparency is adequate but not rich.
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?
Two sentences, no extra words. The first sentence states the core purpose and return format; the second adds a key behavioral detail. Perfectly front-loaded and efficient.
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 simplicity (one parameter, no output schema), the description is fairly complete. It covers the main behavior, output format, and ordering. Missing elements like error handling or file existence checks are minor, and the context is sufficient for effective use.
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% with a description for file_paths. The tool description adds 'Files are merged in the order provided,' which clarifies ordering semantics beyond the schema. This adds meaningful value, earning a score above baseline 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 function: merging multiple PDF files into a single PDF. It specifies the output format (base64-encoded) and that order is preserved. This distinguishes it well from siblings like extract_pages or split_pdf.
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 combining PDFs) but provides no explicit guidance on when to use versus alternatives or when not to use. It mentions order preservation, which is helpful, but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert PDF pages to PNG images. Returns a JSON with base64-encoded PNG images for each page. Supports custom DPI settings for resolution control.
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | Image resolution in dots per inch (default: 150) | |
| format | No | Image format (PNG only) | png |
| file_path | Yes | Path to the PDF file to convert to images |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and does well by disclosing the output format (JSON with base64-encoded PNG images) and custom DPI support. It could be improved by mentioning error handling or large file behavior.
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?
Three sentences, no fluff. Each sentence adds value: first states the action, second describes output, third mentions customization. Front-loaded with key information.
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?
Adequate for a conversion tool with 3 parameters and no output schema, but lacks details on limitations (e.g., max pages, file size) or how DPI affects output. Could be more complete.
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 baseline is 3. The description adds no new meaning beyond the schema: it mentions DPI and format, but those are already described in the schema. No extra value.
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 converts PDF pages to PNG images, which is a specific verb and resource. It distinguishes well from sibling tools like extract_text or extract_metadata, which perform different operations.
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 purpose is clear and the sibling tools cover different functionalities, so the usage context is implied. However, there is no explicit guidance on when to use this tool versus alternatives or any prerequisites.
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 page numbers and context around the found text. Useful for finding specific content in large documents.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to search for in the PDF | |
| file_path | Yes | Path to the PDF file to search within | |
| context_words | No | Number of words to include before and after each match (default: 10) | |
| case_sensitive | No | Whether to perform case-sensitive search (default: False) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return of page numbers and context, but no annotations provided; does not mention if regex is supported, or any side effects. Adequate but not detailed.
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?
Three sentences, front-loaded with purpose. Efficient and free of extraneous wording.
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; description explains return values (page numbers, context). Sufficient for a search tool, but could specify format. Context from siblings is good.
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 baseline 3. Description adds 'returns page numbers and context' but does not elaborate on parameter details beyond schema. No additional meaning.
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?
Clearly states verb 'Search for specific text within a PDF file', specifies resource (PDF). Distinguishes from sibling tools like extract_text (which extracts all text) and fill_form.
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?
Suggests usefulness for finding content in large documents but lacks explicit when-to-use vs when-not-to-use or alternatives. No mention of extract_text for full extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a PDF file into multiple separate PDF files based on page ranges. Returns a JSON with base64-encoded PDFs for each selected page. Supports single pages (e.g., '1'), page ranges (e.g., '1-3'), and all pages (e.g., 'all').
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the PDF file to split | |
| page_range | Yes | Page range to split - 'all', single page (e.g., '1'), or range (e.g., '1-3', '2-5') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that output is a JSON with base64-encoded PDFs and explains supported page range formats ('single page', 'range', 'all'). However, it does not discuss limitations like file size, performance, or handling of overlapping ranges.
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?
Two sentences with no wasted words. The main action is front-loaded, and supporting details (output format, page range examples) follow efficiently.
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 no output schema, the description adequately explains return format (JSON with base64 PDFs) and supported page ranges. However, it could clarify that the tool returns multiple files when multiple pages/ranges are specified. Overall sufficient but not exhaustive.
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 baseline is 3. The description adds value by providing concrete examples for page_range (e.g., '1', '1-3', 'all'), which clarifies usage beyond the schema's generic description.
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?
Description clearly states verb and resource: 'Split a PDF file into multiple separate PDF files based on page ranges.' It distinguishes from siblings like merge_pdfs and extract_pages by specifying the output is multiple separate files rather than extracted content or merged file.
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 explains what the tool does but does not explicitly state when to use it versus alternative tools like extract_pages or merge_pdfs. Usage context is implied through functionality but no when-not or alternative guidance is provided.
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.
v0.1.0extract_metadataextract_pagesextract_textfill_formget_form_fieldsget_page_countmerge_pdfspdf_to_imagessearch_textsplit_pdfEach tool has a clearly distinct purpose: metadata extraction, text extraction, page extraction, form handling, merging, splitting, conversion to images, text search, and page count. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., extract_metadata, merge_pdfs, get_page_count). The naming is predictable and clear.
10 tools cover a well-scoped set of PDF operations without redundancy. The count is appropriate for a utility server handling common PDF tasks.
The tool set covers core PDF workflows: metadata, text extraction, page manipulation, form handling, merging, splitting, search, and conversion. Minor gaps like PDF creation or OCR are absent but not critical for typical use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
PDF engagement layer for apps and agents: tracking links, read analytics, and a full PDF toolset.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Convert and compress PDFs and images, redact personal data, and run text and data utilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gzigurella/pdf-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
