Skip to main content
Glama

Render a document

render
Idempotent

Render a template plus a JSON payload into a PDF, PNG or JPG and return a signed URL. This is the one tool most calls need.

Small jobs finish inside the call and come back status: "succeeded" with a url you can hand straight to a user. Anything with a webhook_url, async: true or a large payload comes back status: "queued" with an id for get_render.

Renders are deterministic and cached: the same template version, data and options return the stored object with cached: true, free and instant. Billing is per PNG or JPG and per PDF page; cache hits are never billed.

For a reader who is not in the US, send data.lang (a BCP 47 tag such as fi or pt-BR) if the template's schema has a lang property (check get_template first; the starter library's templates do for new accounts and after a library refresh): the document's fixed text, dates, money and paper size follow it, and data.labels overrides single strings. On a template that does not declare them they are ordinary unknown fields (a warning, or a 422 on a closed schema). Read warnings in the answer: fields the template did not use, and a language it has no text for.

No API key needed to start — the first call mints a trial of 10 PDF pages or 10 images and returns its token.

Input Schema

NameRequiredDescriptionDefault
dataYesThe JSON payload for the template, matching its schema. Call get_template for the schema, or validate_data to dry-run a payload for free. If get_template shows a `lang` property in the schema, add `lang` (a BCP 47 tag such as `fi` or `pt-BR`) for the reader's language, and `labels` (key to text) to reword single strings. Do not send them to a template whose schema lacks them: they are unknown fields there (a warning on an open schema, a 422 on a closed one).
asyncNoForce the queued path even for a small job. Default false: small jobs finish inside the call and come back with a URL already.
formatNoOutput format. Defaults to `pdf` for chromium templates and `png` for satori ones. `webp` is not supported in v1.
optionsNoRender options, merged over the template's own defaults. Options are part of the cache key, so two calls that differ only here are two different renders.
templateYesTemplate to use: `invoice` for the latest version, or `invoice@3` to pin version 3. Pin the version in anything you ship — a new version changes the output and the cache key. Call list_templates to see what this account has.
webhook_urlNoAbsolute https URL to POST the finished render to. Supplying one forces the queued path: the call returns immediately with status `queued`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / data / description
      Previous value: -"The JSON payload for the template, matching its schema. Call get_template for the schema, or validate_data to dry-run a payload for free."New value: +"The JSON payload for the template, matching its schema. Call get_template for the schema, or validate_data to dry-run a payload for free. If get_template shows a `lang` property in the schema, add `lang` (a BCP 47 tag such as `fi` or `pt-BR`) for the reader's language, and `labels` (key to text) to reword single strings. Do not send them to a template whose schema lacks them: they are unknown fields there (a warning on an open schema, a 422 on a closed one)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / options / properties / margin / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "properties": {
      -      "bottom": {
      -        "type": "string"
      -      },
      -      "left": {
      -        "type": "string"
      -      },
      -      "right": {
      -        "type": "string"
      -      },
      -      "top": {
      -        "type": "string"
      -      }
      -    },
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "properties": {
      +      "bottom": {
      +        "type": [
      +          "string",
      +          "number"
      +        ]
      +      },
      +      "left": {
      +        "type": [
      +          "string",
      +          "number"
      +        ]
      +      },
      +      "right": {
      +        "type": [
      +          "string",
      +          "number"
      +        ]
      +      },
      +      "top": {
      +        "type": [
      +          "string",
      +          "number"
      +        ]
      +      }
      +    },
      +    "type": "object"
      +  }
      +]
    • changedInput schema / properties / options / properties / margin / description
      Previous value: -"PDF margins, CSS lengths: `18mm`, or per side."New value: +"PDF margins, CSS lengths in `in`, `px`, `cm` or `mm`: `18mm`, or per side. A bare number is px."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: deterministic and cached renders with `cached: true`, per-page/per-image billing with cache hits never billed, a first-call trial token of 10 pages/images, and a `warnings` output for unused fields or missing language text. None of this is derivable from readOnly/openWorld/idempotent hints alone.

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-loaded with the core action and the sync/async split, then caching/billing, then the language guidance. Every paragraph carries information, though the lang/labels passage is somewhat dense and could be tightened.

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?

With no output schema, the description supplies the return contract itself: `status: succeeded` with a url, or `status: queued` with an id, plus `cached` and `warnings`. Combined with the rich schema and the async/get_render path, an agent has everything needed to call and follow up correctly.

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 already 100%, so the schema carries most parameter detail. The description still adds real meaning: options are part of the cache key so visually-identical calls can be distinct renders, and version pinning (`invoice@3`) matters for shipped code because new versions change output and cache keys.

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 (render), the resource (template + JSON payload), the output formats (PDF/PNG/JPG) and the return value (signed URL). The line 'This is the one tool most calls need' positions it against the sibling set unambiguously.

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 routes the agent: sync payloads return a url, while webhook_url/async/large payloads queue and must be polled with get_render. It also points to get_template for the schema, validate_data for a dry run, and list_templates for inventory. Clear when-to-use and which alternative to reach for.

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