Skip to main content
Glama
deenesjakoruzh
mrslbt

pdf-it

by mrslbt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pdf-it

pdf-it MCP server MCP Badge npm version npm downloads License: MIT

A Model Context Protocol (MCP) server and Claude Code skill that turns markdown into PDFs that look like they were made on purpose. Cover page, table of contents, code blocks that hold across page breaks, page-numbered footer. One command from your Claude session to a file you can send to a client.

pdf-it cover example

Why this exists

Every Claude Code research session ends the same way: a wall of useful markdown and no clean way to turn it into a PDF a person would want to read. Chrome print is ugly. Manual HTML conversion is friction.

pdf-it does the work. Markdown in, designed PDF out. One command.

pdf-it body example

A 12-page sample is in examples/designing-ai-agent-uiux.pdf.

Related MCP server: Gen-PDF MCP Server

Works with

pdf-it is a standard Model Context Protocol server. Any client that supports MCP locally can use it.

Client

Supported

How to add

Claude Desktop (Mac, Windows)

yes

Edit claude_desktop_config.json

Claude Code (CLI)

yes, plus skill triggers like "save this as PDF"

claude mcp add pdf-it -- npx -y pdf-it-mcp

Cursor

yes

Edit ~/.cursor/mcp.json

Cline (VS Code extension)

yes

Edit Cline's MCP settings

Continue.dev

yes

Add via Continue's MCP config

Zed

yes

Standard MCP config

Goose (Block's CLI)

yes

Standard MCP config

Custom agents via the Anthropic SDK

yes

Wire MCP yourself

claude.ai (browser)

no

Web does not run local MCP servers

Claude iOS / Android

no

Mobile does not run local MCP servers

Hard requirements on any client: Node.js 18 or newer, Google Chrome installed, the client must support MCP.

Install

npm install -g pdf-it-mcp

Or run on demand with npx pdf-it-mcp.

Requirements

  • Node.js 18 or newer

  • Google Chrome installed (used as the renderer, no extra download)

Configure

Claude Desktop

Edit claude_desktop_config.json:

{
  "mcpServers": {
    "pdf-it": {
      "command": "npx",
      "args": ["-y", "pdf-it-mcp"]
    }
  }
}

Claude Code

claude mcp add pdf-it -- npx -y pdf-it-mcp

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "pdf-it": {
      "command": "npx",
      "args": ["-y", "pdf-it-mcp"]
    }
  }
}

Custom Chrome path

If Chrome lives somewhere non-standard:

{
  "mcpServers": {
    "pdf-it": {
      "command": "npx",
      "args": ["-y", "pdf-it-mcp"],
      "env": { "CHROME_PATH": "/path/to/chrome" }
    }
  }
}

Use

In any Claude session connected to the server, ask:

Save this as a PDF

Or any of these phrasings: export as PDF, make a PDF report from this, turn this into a PDF, /pdf. The skill picks up the request and routes it through pdf-it. The output lands in ~/Documents/pdf-it/ by default.

Tools

Tool

Description

generate_pdf

Convert markdown into a PDF. Accepts a template (research-report or plain), optional title and author for the cover, and an optional output path.

list_templates

Return the list of available templates with descriptions.

generate_pdf parameters

Parameter

Required

Description

content

yes

Markdown string to convert

title

no

Shown on the cover and in the page footer

author

no

Shown on the cover

output_path

no

Absolute path for the output. Defaults to ~/Documents/pdf-it/{slug}-{timestamp}.pdf

template

no

research-report (default) or plain

Templates

Name

Description

research-report

Cover page with title, author, and date. Auto-generated table of contents from H1 and H2 headings. Body with proper hierarchy. Footer with title and page number. Best for research, summaries, design docs, reports.

plain

No cover, no TOC. Dense body content only. Best for short notes and quick exports.

Skill

This package ships with a Claude Code skill at SKILL.md. Trigger phrases the skill responds to:

  • save this as PDF

  • export as PDF

  • make a PDF report from this

  • turn this into a PDF

  • generate a PDF

  • /pdf

See SKILL.md for the full skill spec.

Examples

The examples folder has a sample generated PDF (designing-ai-agent-uiux.pdf, 12 pages) and the cover and body screenshots used in this README.

Output

By default PDFs are written to ~/Documents/pdf-it/{slug}-{timestamp}.pdf. Pass output_path to override.

Design

System fonts where possible. Inter for body and headings, JetBrains Mono for code, page numbers, and metadata. Pure white paper, near-black ink, neutral hairline borders, no accent colors. Code blocks render without syntax highlighting on purpose: color choices in PDFs age badly.

If you want a different design language, fork the templates and adjust. They live in src/templates/ and are plain HTML and CSS rendered through Puppeteer.

License

MIT. See LICENSE.

Built by Marsel Bait.

Available Tools

2 tools
generate_pdfA

Convert markdown into a designed PDF (cover page, auto TOC, page-numbered footer). Use this for any "save/export/print/share as PDF", "make a report", "turn this into a PDF", or /pdf request — do NOT fall back to Chrome headless, cupsfilter, wkhtmltopdf, pandoc, or LaTeX. Templates: research-report (cover + TOC, default) or plain (no cover, no TOC).

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesMarkdown content to convert to PDF.
output_pathNoAbsolute path for the output PDF. Defaults to ~/Documents/pdf-it/{title}-{timestamp}.pdf
titleNoDocument title shown on the cover page and footer.
authorNoAuthor name shown on the cover page.
templateNoTemplate to use. "research-report" (default) adds a cover page and table of contents. "plain" renders body content only.research-report

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description must carry behavioral disclosure. It describes output features (cover, TOC, footer) and template effects. Could mention overwrite behavior or directory requirements, but conversion behavior is mostly implied by the task.

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?

Two sentences efficiently cover purpose, usage guidelines, and template options. No redundant information, front-loaded with key details.

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

Completeness4/5

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

Covers main functionality, output features, and templates. Lacks details on error handling or file overwrite, but for a conversion tool with no output schema, it sufficiently prepares the agent to select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3. Description adds value by explaining template behavior (research-report vs plain) and reinforcing that title appears on cover and footer. Not all parameters get extra context, but overall it enhances understanding.

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 explicitly states the tool converts markdown to a designed PDF with cover page, auto TOC, and page-numbered footer. It distinguishes from the only sibling, list_templates, which is clearly different.

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

Usage Guidelines5/5

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

Provides clear when-to-use scenarios (save/export/print/share as PDF, make a report, /pdf request) and explicitly lists alternatives to avoid (Chrome headless, cupsfilter, wkhtmltopdf, pandoc, LaTeX).

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

list_templatesA

List all available PDF templates with their descriptions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses a read operation returning a list with descriptions, but does not mention potential side effects or details like caching.

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, efficient sentence front-loaded with key purpose. No wasted words.

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?

Adequate for a simple list tool with no parameters, but lacks details like ordering, filtering, or scope of templates (e.g., user-specific vs global).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%, so baseline is 4. Description does not need to add parameter info.

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 available PDF templates with descriptions, distinguishing it from the sibling tool 'generate_pdf' which likely generates a PDF from a template.

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?

Implied usage via naming ('list' vs 'generate'), but no explicit guidance on when to use this tool over alternatives.

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.

  1. 2 tool updatesv1.2.0
    • First observedgenerate_pdf
    • First observedlist_templates
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: generating PDFs and listing templates, with no overlap.

Naming Consistency5/5

Both tools follow a consistent verb_noun snake_case pattern (generate_pdf, list_templates), making them predictable.

Tool Count3/5

With only two tools, the server covers the essential PDF generation function but feels minimal for a broader toolkit.

Completeness3/5

The set covers generate and list, but lacks template management (create, update, delete) and advanced options, leaving moderate gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers