Skip to main content
Glama
lanxiukai

mcp-tools Format Conversion

by lanxiukai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

markdown_to_pdf

Convert Markdown files to styled PDFs with selectable rendering engines and color themes, preserving math, tables, code blocks, and clickable links for printing or on-screen reading.

Instructions

Convert a Markdown file (.md) to a styled PDF.

Uses markdown-it-py for parsing. Supports two rendering backends:
- engine="chromium" (default): Uses Playwright/Chromium for PDF output.
  Full MathJax SVG support — recommended for math-heavy documents.
- engine="weasyprint": Lightweight, good for simple documents without math.
Supports Chinese fonts, tables, code blocks, blockquotes, and page numbers.
Three color themes are available: white for printing, warm sepia for
low-glare reading, and a dark theme inspired by One Dark Pro Night Flat.
Preserves clickable web and local file links, including file:// URLs and
relative paths into other repositories, resolved from the source directory.
Call inspect_pdf_links first. Existing unambiguous derived PDFs replace
local Markdown/HTML targets; absent PDFs leave the source link unchanged.
Multiple PDF candidates require pdf_targets; other file formats stay intact.

Args:
    file_path:   Absolute path to the .md file.
    output_path: Absolute path for the output .pdf file.
                 If empty, the PDF is saved next to the source with the
                 same stem (e.g. /tmp/report.md → /tmp/report.pdf).
    engine:      Rendering backend — "chromium" (default) or "weasyprint".
    theme:       Color theme — "print" (white, default), "sepia" (warm),
                 or "one-dark-pro" (One Dark Pro Night Flat-inspired).
    pdf_targets: Reviewed source-to-PDF paths, or null values to keep sources.
                 Relative paths resolve from the source directory.
    pdf_destinations: Original hrefs mapped to fragments from resolve_pdf_destination.
    link_policy: "prefer-pdf" selects existing PDFs; "preserve" keeps sources.

Input Schema

NameRequiredDescriptionDefault
themeNoprint
engineNochromium
file_pathYes
link_policyNoprefer-pdf
output_pathNo
pdf_targetsNo
pdf_destinationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that links with unambiguous derived PDFs get rewritten while absent PDFs are left unchanged, and that link_policy controls preference vs preservation. Gaps remain around overwrite behavior for an existing output_path, permissions, and failure modes, and the link-rewriting sentences are terse enough to be ambiguous.

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

Conciseness4/5

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

Front-loads the core purpose in the first line and organizes backends as a readable list, with no filler sentences. The link-handling paragraph is dense and hard to parse, and the trailing Args block restates schema structure rather than adding narrative flow.

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?

For a 7-parameter, no-annotation, no-output-schema tool, the description covers backends, themes, output defaults, and the inspect_pdf_links prerequisite. An agent could call it correctly from this, though it lacks any indication of what is returned, how long rendering takes, or what happens on an existing output file.

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 0%, so the description must compensate, and it documents all seven parameters including the empty-output_path default rule with a concrete path example and the meaning of each enum value. The weak spot is pdf_destinations, described only as 'original hrefs mapped to fragments from resolve_pdf_destination', which requires reading a sibling tool to understand.

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?

States a specific verb and resource (convert a Markdown .md file to a styled PDF) and names the concrete implementation stack. It is clearly distinguishable from siblings like html_to_pdf and pdf_to_text by source format and direction of conversion.

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

Usage Guidelines4/5

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

Gives actionable routing guidance: chromium is 'recommended for math-heavy documents' while weasyprint is for 'simple documents without math', and it imposes an explicit prerequisite ('Call inspect_pdf_links first'). It also states pdf_targets is required when there are multiple PDF candidates. It does not explicitly compare against sibling html_to_pdf, so it falls short of a full when/when-not map.

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

Deploy Server

Other Tools