Tailprint

render_pdf

Converts HTML with Tailwind CSS, public URLs, or hosted templates with JSON data into vector PDFs, returning a hosted CDN link and base64 data URI.

Instructions

Converts HTML with full Tailwind CSS classes, a public URL, or a hosted template (template_id + JSON data, e.g. "invoice-modern") into a pixel-perfect, vector PDF document with Smart Pagination Shield. Returns a hosted CDN link and base64 data URI.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "render_pdf"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	Public web URL to render directly to PDF (e.g. https://news.ycombinator.com). Provide exactly one of html, url or template_id.
`data`	No	JSON data for template_id (e.g. seller, buyer and items for invoice-modern). Validation errors name the offending fields.
`html`	No	HTML markup to render. Tailwind CSS utility classes are supported automatically. Provide exactly one of html, url or template_id.
`format`	No	Paper format: "A4" or "Letter" (default: "A4")	A4
`delay_ms`	No	Optional delay in milliseconds before rendering (max 5000)
`password`	No	Optional password to encrypt the PDF with AES-256
`wait_for`	No	Optional CSS selector to wait for before rendering
`landscape`	No	Whether to generate PDF in landscape orientation (default: false)
`max_reads`	No	Optional maximum number of reads/downloads before automatic expiration (Geiger read limit)
`expire_mode`	No	How the hosted PDF behaves after expiration: "replace_and_stamp" (selective field decay + EXPIRED stamp), "replace_only" (field replacement only), or "lockout" (1-page expired certificate)
`footer_html`	No	Optional HTML template for page footer (e.g. with pageNumber / totalPages)
`header_html`	No	Optional HTML template for page header (e.g. with pageNumber / totalPages)
`template_id`	No	Hosted template id: invoice-modern, receipt-minimal, certificate-classic or report-executive. Requires "data". Provide exactly one of html, url or template_id.
`document_ttl`	No	Optional Time-Limited Isotope PDF half-life duration (e.g. "24h", "7d", "14d"). Supports <span data-isotope="14d" data-decayed="[EXPIRED]"> in HTML.
`expire_message`	No	Optional custom expiration notice
`print_background`	No	Whether to print CSS backgrounds and colors (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.0Nov 13, 2026

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does usefully state the return shape (hosted CDN link plus base64 data URI), which matters because there is no output schema, but it leaves encryption, TTL/expiration semantics, and read limits to the parameter descriptions. "Smart Pagination Shield" and "pixel-perfect" are unverifiable marketing terms rather than disclosed behavior.

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?

Two sentences, with the input modes front-loaded before the return value, so it is dense rather than padded. Still, phrases like "pixel-perfect" and "Smart Pagination Shield" are promotional and add no decision-relevant meaning.

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?

For a 16-parameter tool with no output schema and no annotations, the description covers inputs and return format at a high level, and the rich schema fills the rest. It does not explain the interplay among document_ttl, max_reads and expire_mode, or what password encryption implies for the consumer, so an agent handling those options must rely entirely on schema text.

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 description coverage is 100%, with all 16 parameters documented, enums enumerated, and constraints stated, so the baseline is 3. The description reinforces the mutually exclusive input modes and repeats the template_id example ("invoice-modern") already in the schema, adding only marginal value beyond that baseline.

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 states a specific verb and resource ("Converts ... into a ... PDF document") and enumerates the three input modes: HTML with Tailwind, a public URL, or a hosted template. It doesn't distinguish itself from the nearby render_template or render_presentation tools, which keeps it short of a 5.

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?

There is no guidance on when to use this tool instead of render_template or render_presentation, and no stated prerequisites. The only routing rule, "provide exactly one of html, url or template_id," is already in the schema property descriptions, so the description adds no selection guidance.

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

Deploy Server