Skip to main content
Glama
papertype-dev

papertype-mcp

Official
by papertype-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render a PDF with PaperType

render_pdf

Convert Markdown, HTML, or a filled template into a PDF saved to disk. Returns the file path and page count, with hosted templates for invoices, certificates, and reports.

Instructions

Render a PDF from Markdown, HTML, or a hosted template (invoice, certificate, report) using the PaperType API, and save it to disk. Returns the absolute file path, page count and remaining quota; the PDF bytes are never returned inline. Provide exactly one source: markdown, html, or template + data. Each call uses one document of the account's monthly quota.

Input Schema

NameRequiredDescriptionDefault
cssNoExtra CSS appended after the theme (markdown/html). May include @page rules, e.g. '@page { margin: 2cm }'.
tocNoAdd a table of contents built from headings. Markdown input only. Default false.
dataNoJSON object of fields for the chosen template (required when template is set). Shape per template is shown by list_templates.
dateNoDate text shown on the cover page, e.g. '2026-10-18' or 'October 2026'.
htmlNoHTML document or fragment to render. A theme wraps it in page styles unless theme is 'none'. Provide exactly one of markdown, html, or template+data.
coverNoAdd a cover page with title, author and date (markdown/html). Default false.
themeNoPage style for markdown/html input. 'clean' (default, general documents), 'report' (formal, good with cover+toc), 'minimal' (plain), 'letter' (correspondence), 'none' (HTML only: no theme, just your own CSS). Ignored for templates.
titleNoDocument title: used for the PDF metadata, the cover page, and the default output filename.
authorNoAuthor shown on the cover page and in PDF metadata.
footerNoFooter text printed bottom-left on every page (e.g. a confidentiality note).
headerNoRunning header text printed top-right on every page.
filenameNoSuggested file name (e.g. 'invoice-014.pdf'). Used for the saved file's name when output_path is not given.
markdownNoMarkdown source for the document (GitHub-flavoured: headings, lists, tables, fenced code, footnotes, admonitions). Provide exactly one of markdown, html, or template+data.
templateNoName of a hosted template to fill with `data` instead of writing markdown/html: 'invoice', 'certificate' or 'report'. Call list_templates to see each template's fields and sample data.
page_sizeNoPaper size. Default A4. Use 'Letter' for US documents.
output_pathNoWhere to save the PDF. Omit to get a unique file named after the title under the server's output directory (PAPERTYPE_OUTPUT_DIR, default <tmp>/papertype). An existing directory (or a path ending in '/') saves a uniquely named file inside it. Any other path is used as the exact file name ('.pdf' appended if missing; an existing file is overwritten). Relative paths resolve against the output directory.
page_numbersNoPrint page numbers in the footer. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds useful behavioral detail beyond annotations: it returns the absolute file path, page count, and remaining quota, explicitly says PDF bytes are never returned inline, and flags quota consumption. It omits overwrite behavior, though the output_path schema covers that.

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 four tight sentences with no wasted language. The core action and output behavior are front-loaded, followed by source constraints and quota impact.

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 17-parameter tool with no output schema, the description does well: it explains return values, quota consumption, and source constraints. It could be slightly more complete by explicitly pointing template users to list_templates for data shape, but the schema already contains that pointer.

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 17 parameters in detail, including the exactly-one-source rule. The description restates the mutual exclusivity of markdown/html/template+data and names the template types, but adds little parameter-level meaning beyond what the schema already provides.

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 states a specific verb and resource ('Render a PDF'), names the three supported source types, and specifies that the result is saved to disk. That is enough for an agent to distinguish this tool from list_templates and account without opening the schema.

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?

It gives clear context for source selection ('provide exactly one source') and notes that each call consumes one monthly document quota. It does not explicitly say when to use this tool versus siblings or when not to use it, but the operational context is clear.

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