Skip to main content
Glama
Theorhd

PDF-Tools MCP Server

by Theorhd
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

PDF-Tools MCP Server v1.0.0

A Model Context Protocol (MCP) server for PDF generation and manipulation. This server provides tools to generate PDF documents from HTML, text, and Markdown content.

Features

  • HTML to PDF: Convert HTML content to PDF using Puppeteer

  • Text to PDF: Generate PDF from plain text using PDFKit

  • Markdown to PDF: Convert Markdown content to styled PDF

  • Cross-platform: Works on Windows, macOS, and Linux

  • Dynamic paths: Automatically uses user's home directory

  • Secure: Validates output paths to allowed directories

Related MCP server: Yakpdf MCP Server

Installation

Prerequisites

  • Node.js 18 or higher

  • npm or yarn

Clone and Install

git clone https://github.com/Theorhd/Pdftools-mcp.git
cd Pdftools-mcp
npm install

Build

npm run build

Usage

As MCP Server

Add to your MCP client configuration (e.g., Jan):

{
  "mcpServers": {
    "pdf-creator": {
      "command": "node",
      "args": ["path/to/pdftools-mcp/dist/index.js"],
      "env": {},
      "type": "stdio",
      "active": true
    }
  }
}

Standalone

npm start

Tools

generate_pdf_from_html

Generate a PDF from HTML content using Puppeteer.

Parameters:

  • html_content (string, required): HTML content to convert

  • output_filename (string, required): Output PDF filename

  • output_dir (string, optional): Output directory (defaults to Downloads)

  • options (object, optional): PDF generation options

    • format (string): Page format (default: A4)

    • margin (object): Page margins

Example:

{
  "html_content": "<h1>Hello World</h1><p>This is a test PDF.</p>",
  "output_filename": "test.pdf",
  "options": {
    "format": "A4",
    "margin": {
      "top": "1cm",
      "right": "1cm",
      "bottom": "1cm",
      "left": "1cm"
    }
  }
}

generate_pdf_from_text

Generate a PDF from plain text using PDFKit.

Parameters:

  • text_content (string, required): Text content to convert

  • output_filename (string, required): Output PDF filename

  • output_dir (string, optional): Output directory (defaults to Downloads)

  • options (object, optional): PDF formatting options

    • fontSize (number): Font size (default: 12)

    • font (string): Font family (default: Helvetica)

    • margins (object): Page margins

Example:

{
  "text_content": "Hello World!\n\nThis is a test PDF generated from plain text.",
  "output_filename": "text-example.pdf",
  "options": {
    "fontSize": 14,
    "font": "Helvetica",
    "margins": {
      "top": 50,
      "left": 50,
      "right": 50,
      "bottom": 50
    }
  }
}

generate_pdf_from_markdown

Generate a PDF from Markdown content with automatic HTML conversion.

Parameters:

  • markdown_content (string, required): Markdown content to convert

  • output_filename (string, required): Output PDF filename

  • output_dir (string, optional): Output directory (defaults to Downloads)

Example:

{
  "markdown_content": "# Hello World\n\nThis is a **bold** text and this is *italic*.\n\n## Subheading\n\n- List item 1\n- List item 2\n\n`code example`",
  "output_filename": "markdown-example.pdf"
}

Security

The server validates all output paths to ensure files are only written to allowed directories:

  • User's Downloads folder

  • User's Documents folder

  • User's Desktop folder

Any attempt to write outside these directories will result in an error.

Development

Scripts

  • npm run build: Compile TypeScript to JavaScript

  • npm start: Run the compiled server

  • npm run dev: Run in development mode with tsx

  • npm test: Run tests

Project Structure

pdftools-mcp/
├── src/
├── dist/           # Compiled JavaScript
├── index.ts        # Main server file
├── package.json
├── tsconfig.json
└── README.md

Dependencies

  • @modelcontextprotocol/sdk: MCP protocol implementation

  • puppeteer: HTML to PDF conversion

  • pdfkit: PDF generation from text

  • typescript: TypeScript compiler

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

License

MIT License - see LICENSE file for details.

Troubleshooting

Common Issues

Puppeteer fails to launch:

  • Ensure you have the required system dependencies

  • On Linux: sudo apt-get install -y gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget

Permission errors:

  • Ensure the output directory exists and is writable

  • Check that the user has permissions to write to the target directory

Module not found errors:

  • Run npm install to ensure all dependencies are installed

  • Rebuild the project with npm run build

Support

For issues and questions:

  • Create an issue on GitHub

  • Check existing issues for solutions

  • Review the troubleshooting section above

Available Tools

4 tools
generate_pdf_from_htmlC

Generate a PDF from HTML content using Puppeteer

ParametersJSON Schema
NameRequiredDescriptionDefault
html_contentYesHTML content to convert to PDF
output_filenameYesName of the output PDF file (without path)
output_dirNoOutput directory (optional, defaults to Downloads)/root/Downloads
optionsNoPDF generation options

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'using Puppeteer' which hints at browser-based rendering, but doesn't disclose critical behaviors like whether this is a blocking/long-running operation, error handling, file system impacts, or authentication needs. For a tool that generates files with 4 parameters, this is insufficient.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward conversion tool and front-loads the core functionality. 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?

For a tool with 4 parameters, nested objects, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after generation (where the file goes, return values), error conditions, performance characteristics, or how it differs from sibling tools. The 100% schema coverage helps but doesn't compensate for missing behavioral context.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions 'HTML content' and 'PDF' which aligns with parameters but doesn't provide additional context about format requirements, constraints, or usage examples.

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 'Generate' and resource 'PDF from HTML content', specifying the conversion purpose. It distinguishes from siblings by mentioning 'HTML content' (vs. markdown/text for other tools) and 'using Puppeteer' as the implementation method. However, it doesn't explicitly contrast with sibling tools like '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?

The description provides no guidance on when to use this tool versus alternatives like 'generate_pdf_from_markdown' or 'generate_pdf_from_text'. It doesn't mention prerequisites, constraints, or typical use cases. The only implied usage is converting HTML to PDF, but no context for choosing between sibling tools is given.

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

generate_pdf_from_markdownC

Generate a PDF from Markdown content

ParametersJSON Schema
NameRequiredDescriptionDefault
markdown_contentYesMarkdown content to convert to PDF
output_filenameYesName of the output PDF file (without path)
output_dirNoOutput directory (optional, defaults to Downloads)/root/Downloads

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates a PDF but doesn't describe what happens during generation (e.g., file creation, overwriting behavior, error handling), permissions needed, or rate limits. For a tool that creates files, this is a significant gap in transparency.

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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or redundancy are present.

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 the tool's complexity (file generation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, file path), error conditions, or behavioral details. For a tool that creates output files, this leaves significant gaps for an 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't compensate with additional context about parameter interactions or constraints.

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's purpose: 'Generate a PDF from Markdown content' - a specific verb (generate) and resource (PDF from Markdown). It distinguishes from sibling tools like generate_pdf_from_html and generate_pdf_from_text by specifying the input format. However, it doesn't explicitly contrast with read_pdf, which serves a different purpose.

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 alternatives. It doesn't mention when to choose markdown over HTML or text for PDF generation, nor does it address prerequisites or exclusions. The agent must infer usage from the tool name alone.

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

generate_pdf_from_textC

Generate a PDF from plain text using PDFKit

ParametersJSON Schema
NameRequiredDescriptionDefault
text_contentYesText content to convert to PDF
output_filenameYesName of the output PDF file (without path)
output_dirNoOutput directory (optional, defaults to Downloads)/root/Downloads
optionsNoPDF formatting options

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates a PDF but doesn't mention critical behaviors: whether it overwrites existing files, requires specific permissions, handles errors, or what the output looks like (e.g., file path). For a tool that creates files, this lack of transparency about side effects and outcomes is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence: 'Generate a PDF from plain text using PDFKit'. It's front-loaded with the core purpose, uses no unnecessary words, and clearly communicates the essential action. Every part of the sentence earns its place by specifying the output (PDF), input (plain text), and method (PDFKit).

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 the complexity (4 parameters including nested objects, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like file creation side effects, error handling, or output details. For a tool that generates files, more context is needed about what happens after invocation, especially without annotations or output schema to fill these gaps.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. It doesn't explain parameter interactions, provide examples, or clarify semantics like what 'plain text' entails versus HTML/markdown. The baseline score of 3 reflects adequate schema coverage without description enhancement.

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's purpose: 'Generate a PDF from plain text using PDFKit'. It specifies the verb ('Generate'), resource ('PDF'), and source format ('plain text'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like generate_pdf_from_html or generate_pdf_from_markdown, which handle different input formats.

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 alternatives. It doesn't mention sibling tools (generate_pdf_from_html, generate_pdf_from_markdown, read_pdf) or specify scenarios where plain text conversion is preferred over other formats. There's also no information about prerequisites or constraints, leaving usage context unclear.

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

read_pdfB

Read a PDF file from disk and return its text content

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute or relative path to the PDF file

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool reads from disk and returns text content, but doesn't mention error handling (e.g., what happens if the file doesn't exist or isn't a PDF), performance characteristics, or any limitations (e.g., file size constraints, text extraction accuracy). This leaves significant gaps for a tool that interacts with the filesystem.

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, efficient sentence that states exactly what the tool does. It's front-loaded with the core action and includes the key details (source and output). There's no wasted language or unnecessary elaboration.

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?

Given the tool's moderate complexity (filesystem interaction, PDF parsing) and lack of annotations/output schema, the description is minimally adequate. It covers the basic operation but lacks details about error conditions, performance, or output format beyond 'text content'. For a tool with no structured safety or output information, more behavioral context would be helpful.

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 description coverage is 100%, so the schema already fully documents the single parameter 'file_path'. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage, the baseline is 3 even with no param info in the description.

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's purpose with specific verb ('Read') and resource ('PDF file'), and specifies what it returns ('text content'). It doesn't explicitly distinguish from sibling tools, which are all PDF generators rather than readers, so it's clear but lacks explicit sibling differentiation.

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

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 alternatives. It doesn't mention the sibling tools (all PDF generators) or any other context for usage decisions. The agent must infer usage from the tool name and description alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • Addedread_pdf
  2. 3 tool updates
    • First observedgenerate_pdf_from_html
    • First observedgenerate_pdf_from_markdown
    • First observedgenerate_pdf_from_text
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: three tools generate PDFs from different input formats (HTML, Markdown, text), and one tool reads PDFs. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the input type or desired action.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'generate_pdf_from_' or 'read_pdf', using snake_case throughout. This predictability helps agents understand and use the tools efficiently without confusion from mixed conventions.

Tool Count5/5

With 4 tools, the server is well-scoped for PDF processing, covering key operations: generation from multiple sources and reading. Each tool earns its place, providing a focused and manageable set that aligns with the server's purpose without being too sparse or overwhelming.

Completeness4/5

The tool set covers core PDF operations well, including generation from common formats and reading. A minor gap exists in lacking tools for editing or manipulating existing PDFs (e.g., merge, split, annotate), but agents can still handle basic workflows effectively with the provided tools.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP MD2PDF Server

    valyc0
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides tools for converting Markdown content and files into professional PDF documents with full support for Mermaid diagrams and LaTeX rendering. It allows for high-quality output customization, including paper size, table of contents, and syntax highlighting styles.
    -

  • md-mermaid-to-pdf-mcp

    skmprb
    F
    license
    Not graded
    quality
    D
    maintenance
    Converts Markdown files and raw content into professionally styled PDFs with full support for Mermaid diagrams and syntax highlighting. It offers customizable page formats, margins, and modern typography for high-quality document generation.
    11
    -

Appeared in Searches

Latest Blog Posts

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/Theorhd/Pdftools-mcp'

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