Skip to main content
Glama
mrslbt

pdf-it

by mrslbt

pdf-it

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

一个模型上下文协议 (MCP) 服务器和 Claude Code 技能,可将 Markdown 转换为看起来非常专业的 PDF。包含封面、目录、跨页代码块以及带页码的页脚。只需在 Claude 会话中输入一条命令,即可生成可发送给客户的文件。

pdf-it 封面示例

为什么会有这个项目

每个 Claude Code 研究会话的结局都一样:留下一堆有用的 Markdown,却找不到一种简洁的方法将其转换为人们愿意阅读的 PDF。Chrome 打印效果很丑,手动转换为 HTML 又太麻烦。

pdf-it 解决了这个问题。输入 Markdown,输出设计精美的 PDF。只需一条命令。

pdf-it 正文示例

examples/designing-ai-agent-uiux.pdf 中提供了一个 12 页的示例。

Related MCP server: Gen-PDF MCP Server

兼容性

pdf-it 是一个标准的模型上下文协议 (MCP) 服务器。任何在本地支持 MCP 的客户端都可以使用它。

客户端

是否支持

添加方式

Claude Desktop (Mac, Windows)

是

编辑 claude_desktop_config.json

Claude Code (CLI)

是,支持如“save this as PDF”等技能触发

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

Cursor

是

编辑 ~/.cursor/mcp.json

Cline (VS Code 扩展)

是

编辑 Cline 的 MCP 设置

Continue.dev

是

通过 Continue 的 MCP 配置添加

Zed

是

标准 MCP 配置

Goose (Block 的 CLI)

是

标准 MCP 配置

通过 Anthropic SDK 的自定义代理

是

自行配置 MCP

claude.ai (浏览器)

否

Web 端无法运行本地 MCP 服务器

Claude iOS / Android

否

移动端无法运行本地 MCP 服务器

对任何客户端的硬性要求:Node.js 18 或更高版本,已安装 Google Chrome,且客户端必须支持 MCP。

安装

npm install -g pdf-it-mcp

或者使用 npx pdf-it-mcp 按需运行。

要求

  • Node.js 18 或更高版本

  • 已安装 Google Chrome(用作渲染器,无需额外下载)

配置

Claude Desktop

编辑 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

添加到 ~/.cursor/mcp.json:

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

自定义 Chrome 路径

如果 Chrome 安装在非标准位置:

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

使用

在任何连接到该服务器的 Claude 会话中,询问:

Save this as a PDF

或者使用以下任何措辞:export as PDF、make a PDF report from this、turn this into a PDF、/pdf。该技能会捕获请求并通过 pdf-it 进行处理。输出文件默认保存在 ~/Documents/pdf-it/ 中。

工具

工具

描述

generate_pdf

将 Markdown 转换为 PDF。接受模板(research-report 或 plain)、可选的封面标题和作者,以及可选的输出路径。

list_templates

返回可用模板及其描述的列表。

generate_pdf 参数

参数

必填

描述

content

是

要转换的 Markdown 字符串

title

否

显示在封面和页脚中

author

否

显示在封面中

output_path

否

输出的绝对路径。默认为 ~/Documents/pdf-it/{slug}-{timestamp}.pdf

template

否

research-report(默认)或 plain

模板

名称

描述

research-report

包含标题、作者和日期的封面。根据 H1 和 H2 标题自动生成目录。正文具有清晰的层级结构。页脚包含标题和页码。最适合研究报告、摘要、设计文档和报告。

plain

无封面,无目录。仅包含紧凑的正文内容。最适合简短笔记和快速导出。

技能

此包附带一个位于 SKILL.md 的 Claude Code 技能。该技能响应的触发短语包括:

  • save this as PDF

  • export as PDF

  • make a PDF report from this

  • turn this into a PDF

  • generate a PDF

  • /pdf

请参阅 SKILL.md 获取完整的技能规范。

示例

examples 文件夹中包含一个生成的 PDF 示例(designing-ai-agent-uiux.pdf,12 页)以及本 README 中使用的封面和正文截图。

输出

默认情况下,PDF 会写入 ~/Documents/pdf-it/{slug}-{timestamp}.pdf。传入 output_path 可覆盖此路径。

设计

尽可能使用系统字体。正文和标题使用 Inter,代码、页码和元数据使用 JetBrains Mono。纯白纸张,近黑色墨水,中性细边框,无强调色。代码块特意不使用语法高亮:PDF 中的颜色选择往往会过时。

如果您想要不同的设计语言,请 fork 模板并进行调整。它们位于 src/templates/ 中,是通过 Puppeteer 渲染的纯 HTML 和 CSS。

许可证

MIT。请参阅 LICENSE。

由 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

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

Related MCP Connectors

Related MCP Servers