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., "@Nutrient PDF MCP Server show the PDF object tree for document.pdf with lazy mode"
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 powerful Model Context Protocol server for LLM-driven PDF document analysis and exploration
Server | Best for | Deployment | Core capabilities |
Cloud document workflows | Nutrient-hosted API (API key) | Convert, OCR, redact, sign, extract, watermark, automation | |
Self-hosted document workflows | On-prem/private cloud | Document processing with deployment control and data residency | |
Low-level PDF inspection/debugging | Local Python runtime | Object-tree exploration, indirect-object resolution, structural analysis |
You are in the PDF MCP Server repo. Choose this when you need low-level PDF object-tree inspection/debugging rather than end-to-end workflow automation.
Ecosystem overview: Nutrient AI Infrastructure
Product landing page: Nutrient MCP Server
A Model Context Protocol (MCP) server for investigating PDF object trees with lazy loading support. This tool allows LLMs to efficiently explore PDF document structure without overwhelming token limits.
Related MCP server: PDF Splitter MCP Server
Lazy Loading: Explore PDF structure without loading entire object trees
Path Navigation: Navigate through PDF objects using dot notation (e.g., Pages.Kids.0)
Selective Resolution: Resolve specific indirect objects on demand
Token Efficient: Massive reduction in response sizes compared to full tree dumps
Type Safe: Comprehensive type hints and error handling
asdf setupYou'll need python and nodejs installed on your machine. You can optionally use asdf.
Finally install required tools with:
git clone https://github.com/PSPDFKit/nutrient-pdf-mcp-server.git
cd nutrient-pdf-mcp-server
asdf install
# Install pipx for Python
python -m pip install --user pipxProceed with the rest of the installation after that.
git clone https://github.com/PSPDFKit/nutrient-pdf-mcp-server.git
cd nutrient-pdf-mcp-server
make install-dev # Sets up development environmentRecommended: Build and Install
pip install build
make build
pipx install dist/nutrient_pdf_mcp-1.0.0-py3-none-any.whl
claude mcp add nutrient-pdf-mcp nutrient-pdf-mcpIf using asdf, you might need to configure pipx with the following before running:
export PIPX_DEFAULT_PYTHON=$(asdf which python)
pipx install dist/nutrient_pdf_mcp-1.0.0-py3-none-any.whlDevelopment Mode
make install-dev
claude mcp add nutrient-pdf-mcp "$(pwd)/venv/bin/python" -m pdf_mcp.server{
"mcpServers": {
"nutrient-pdf-mcp": {
"command": "python",
"args": ["-m", "pdf_mcp.server"]
}
}
}get_pdf_object_treeNutrient PDF MCP Server - Get JSON representation of PDF object tree with lazy loading.
Parameters:
pdf_path (required): Path to the PDF file
object_id (optional): Specific object ID to retrieve (e.g., '1 0')
path (optional): Object path to navigate (e.g., 'Pages.Kids.0')
mode (optional): Parsing mode - 'lazy' (default) or 'full'
Examples:
{
"pdf_path": "document.pdf",
"mode": "lazy"
}{
"pdf_path": "document.pdf",
"path": "Pages.Kids.0",
"mode": "lazy"
}resolve_indirect_objectNutrient PDF MCP Server - Resolve a specific indirect object by its object and generation numbers.
Parameters:
pdf_path (required): Path to the PDF file
objnum (required): PDF object number (e.g., 3)
gennum (optional): PDF generation number (defaults to 0)
depth (optional): Resolution depth - 'shallow' (default) or 'deep'
Examples:
{
"pdf_path": "document.pdf",
"objnum": 3,
"gennum": 0,
"depth": "shallow"
}# Run the server
make serve
# Or run with debug logging
make serve-debugparser.py: Main PDF parsing logic with lazy loading support
server.py: MCP server implementation
types.py: Type definitions for PDF objects and responses
exceptions.py: Custom exception classes
All PDF objects are serialized into a consistent JSON format:
{
"type": "dict",
"value": {
"/Type": { "type": "name", "value": "/Pages" },
"/Kids": {
"type": "array",
"value": [{ "type": "indirect_ref", "objnum": 2, "gennum": 0 }]
}
}
}The lazy loading system provides massive token savings:
Lazy mode: ~5-50 lines (minimal tokens)
Shallow resolution: ~50-100 lines (reasonable tokens)
Deep resolution: 500+ lines (use sparingly)
Get overview: get_pdf_object_tree(path="document.pdf", mode="lazy")
Navigate to pages: get_pdf_object_tree(path="document.pdf", path="Pages", mode="lazy")
Resolve specific page: resolve_indirect_object(objnum=3, gennum=0, depth="shallow")
Deep dive when needed: resolve_indirect_object(objnum=3, gennum=0, depth="deep")
"Pages" - Navigate to Pages object
"Pages.Kids" - Get Kids array from Pages
"Pages.Kids.0" - Get first page
"Pages.Kids.0.MediaBox.2" - Get width from MediaBox array
# Set up development environment
make install-dev
# Run all quality checks (format, lint, typecheck, test)
make quality
# Or run individual commands
make test # Run tests
make format # Format code
make lint # Run linter
make typecheck # Type checkingnutrient-pdf-mcp-server/
├── pdf_mcp/
│ ├── __init__.py
│ ├── server.py # MCP server
│ ├── parser.py # PDF parsing logic
│ ├── types.py # Type definitions
│ └── exceptions.py # Custom exceptions
├── tests/ # Test suite
├── res/ # Sample PDFs
├── pyproject.toml # Project configuration
└── README.md# Build the package
make build
# Upload to test PyPI first
twine upload --repository testpypi dist/*
# Upload to production PyPI
twine upload dist/*After publishing, users can install with:
pipx install nutrient-pdf-mcp
# or
pip install --user nutrient-pdf-mcpFork the repository
Create a feature branch
Make your changes with tests
Ensure code quality checks pass
Submit a pull request
MIT License - see LICENSE file for details.
Nutrient PDF MCP Server - Get JSON representation of PDF object tree with lazy loading
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | Path to the PDF file | |
| object_id | No | Optional: specific object ID to retrieve (e.g., '1 0') | |
| path | No | Optional: object path to navigate (e.g., 'Pages.Kids.0') | |
| mode | No | Parsing mode: 'lazy' (default) or 'full' | lazy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions lazy loading, which is a key behavioral trait. However, with no annotations provided, the description carries the full burden. It does not state whether the tool is read-only, what happens if the PDF is malformed, or provide any concurrency or rate limit information. The lazy loading mention is a minimal but useful disclosure.
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 concise sentence with no wasted words. It front-loads the key purpose ('Get JSON representation of PDF object tree') and includes the server context. It is appropriately short for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the medium complexity (4 parameters, one sibling tool) and no output schema, the description is minimally complete. It covers the basic purpose and lazy loading but lacks return value expectations, error handling hints, or usage scenarios. The sibling tool is not explained, leaving the agent to guess when to use each.
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 baseline is 3. The description does not add any meaning beyond what the schema already provides; it simply restates the overall purpose. The schema descriptions for each parameter are clear and complete, so the description's lack of additional parameter context is acceptable.
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 states 'Get JSON representation of PDF object tree' which is a clear verb and resource. It distinguishes from the sibling tool 'resolve_indirect_object' implicitly by focusing on the full tree rather than indirect object resolution. The mention of lazy loading adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its sibling 'resolve_indirect_object'. There is no mention of prerequisites, limitations, or alternative tools for different use cases. The description does not help the agent decide between this and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nutrient PDF MCP Server - Resolve a specific indirect object by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | Path to the PDF file | |
| objnum | Yes | PDF object number | |
| gennum | No | PDF generation number (optional, defaults to 0) | |
| depth | No | Resolution depth: 'shallow' (default, only direct properties) or 'deep' (resolve all nested objects) | shallow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits such as whether the tool is read-only, has side effects, or requires specific permissions. It simply states 'resolve', which is vague, and fails to mention any limitations or consequences, making it insufficient for safe usage.
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 without unnecessary details, but it includes the preamble 'Nutrient PDF MCP Server -', which adds slight noise. It is concise overall, but could be more direct by removing the prefix.
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?
The description is extremely brief and does not explain what an indirect object is, how resolution works, the expected output, or any error handling. Given the lack of annotations and output schema, this is far from complete enough for an agent to use the tool confidently.
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 schema already describes all parameters with 100% coverage, so the description adds no additional semantic value beyond the schema. The baseline of 3 is appropriate as the description does not clarify the meaning of parameters like 'depth' or how to use them effectively.
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 (resolve) and the resource (indirect object by its ID), making it easy to understand the tool's purpose. However, it does not explicitly differentiate from the sibling tool 'get_pdf_object_tree', which might also involve object retrieval, but the focus on a specific object by ID is implied.
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 'get_pdf_object_tree'. There is no mention of context, prerequisites, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: one retrieves the entire object tree structure, the other resolves a specific indirect object by ID. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern with underscore: 'get_pdf_object_tree' and 'resolve_indirect_object'. The naming is uniform and predictable.
With only 2 tools, the surface is minimal but appropriate for the narrow domain of PDF object tree inspection. It's borderline, but each tool serves a specific, complementary purpose.
For the stated purpose of exploring a PDF object tree, the tools provide tree retrieval and resolution of indirect objects. However, missing operations like filtering objects by type or searching objects limit completeness for more advanced use cases.
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.
Agent-native document parsing: PDF, scans and FR/EU invoices to structured JSON or Markdown.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PSPDFKit/nutrient-pdf-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
