Skip to main content
Glama

Print HTML to PDF

render_pdf

Lays out a whole HTML document (with its CSS) as paged print and returns a download link to the PDF, valid 24 hours, and the document's edit link in the ReflowPDF editor (give the person both). Use @page for paper and margins, margin boxes for headers, footers and page numbers; JavaScript does not run. Read read_guide topic "html" before the first document. To change the document later, use update_document with its document_id.

Input Schema

NameRequiredDescriptionDefault
htmlYesThe whole HTML document: <!doctype html>, <html lang>, a <title>, a <style> in <head> with @page. Self-contained; images and fonts by https URL, data: URI or an upload_image link.
previewNoA picture (PNG) of page 1 comes with the answer, so you can check the layout, fonts and images before giving the links. Default: true.
filenameNoThe PDF file name, e.g. "invoice-1042.pdf". Default: the document's <title>.

Output Schema

NameRequiredDescriptionDefault
urlYesThe link, valid 24 hours.
markYesWhether the PDF carries the ReflowPDF mark, and why.
bytesYes
notesYesWhat to tell the person about this PDF.
pagesYes
timingNoThe engine's own parts of it, when it states them: layoutMs (styles, layout and pagination) and writeMs (writing the PDF).
editUrlNoThe document in the ReflowPDF editor: the person edits it there (the link is the document; it lasts while it is used).
previewNoWhat picture of the PDF came with this answer (page 1, as PNG), or why none did.
filenameYes
renderMsNoHow long the print took on the server, in milliseconds (the engine and its adapter).
revisionNoIts revision: name it to update_document as base_revision.
expiresAtYesWhen the link stops working (ISO 8601).
documentIdNoThe document, for get_document and update_document.
missingVariablesNoTemplate values the data did not have (printed empty).
skippedResourcesNoImages, fonts or style sheets the server could not fetch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / preview
      Added value: +{
      +  "description": "A picture (PNG) of page 1 comes with the answer, so you can check the layout, fonts and images before giving the links. Default: true.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / preview
      Added value: +{
      +  "description": "What picture of the PDF came with this answer (page 1, as PNG), or why none did.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / renderMs
      Added value: +{
      +  "description": "How long the print took on the server, in milliseconds (the engine and its adapter).",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / timing
      Added value: +{
      +  "description": "The engine's own parts of it, when it states them: layoutMs (styles, layout and pagination) and writeMs (writing the PDF).",
      +  "properties": {
      +    "layoutMs": {
      +      "type": "number"
      +    },
      +    "writeMs": {
      +      "type": "number"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Adds substantial context beyond annotations: the download link expires in 24 hours, JavaScript does not run, and the response contains two links that must both be surfaced. Annotations already cover the safety profile (openWorld, non-idempotent, non-destructive), and the description complements them rather than contradicting. It stops short of stating explicitly that each render creates a new persistent document, which the 'edit link' and update_document reference only imply.

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?

Front-loaded with the core action and outputs, then prerequisites and authoring hints. Every sentence carries distinct information (outputs, expiry, CSS technique, JS limitation, prerequisite reading, follow-up tool) with no redundancy.

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

Completeness5/5

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

Even though an output schema exists, the description explains the practical return values (two links, 24h expiry) and the preview/filename defaults are covered in the schema. Prerequisites, follow-up path, and CSS authoring constraints are all present, so an agent can call this correctly on the first attempt.

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 the baseline is 3, but the description adds real meaning about the html parameter's required shape (@page for paper and margins, margin boxes for headers/footers/page numbers, no JavaScript) and clarifies that both returned links should be given to the user. This is guidance the schema alone would not supply.

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 ('lays out a whole HTML document ... as paged print') plus the concrete output (a PDF download link valid 24 hours and an editor edit link). It also distinguishes itself from siblings by naming update_document for later edits and read_guide for prerequisites.

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?

Explicitly tells the agent to read read_guide topic "html" before the first document, and to use update_document with document_id for subsequent changes rather than re-rendering. The 'give the person both' instruction and the @page/margin-box guidance define how to use it correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources