Skip to main content
Glama

hedwigai

Render a document to PDF

render_document
Idempotent

Compiles a document you wrote — LaTeX, Typst or Markdown — to a PDF, files it in this account's own storage, and returns a link the user can open (it lasts about six days).

latex is real TeX (Tectonic, XeTeX underneath): journal and conference classes such as IEEEtran, acmart and elsarticle set the page as they would on the author's machine, and BibTeX bibliographies are built. The source is the main .tex; put the rest of the project — chapters, a refs.bib, a .cls — in files, and images either as base64 in files or as assets URLs. Shell escape is off, so minted does not run (use listings); biber is not available (use BibTeX). The first compile of a rarely used package can take a minute while it is fetched.

typst is a complete Typst document; packages from Typst Universe (#import "@preview/…") work. markdown is set in a clean report style, with LaTeX maths in $…$ and $$…$$.

If the source does not compile, the compiler's own message comes back — for LaTeX, the line that failed: fix the source and call again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA file name for the PDF, without extension, e.g. 'thesis-chapter-2'. Optional.
filesNoLaTeX only: the rest of the project beside the main file. Each {path, text} for a .tex, .bib, .cls or .sty, or {path, base64} for an image or other binary file. Paths are relative, as the source refers to them, e.g. chapters/intro.tex or figures/plot.png.
assetsNoFiles the source refers to by relative path, fetched before compiling (latex or typst). Each {url, path}: a public https URL and the path the source uses, e.g. {"url": "https://example.org/plot.png", "path": "figures/plot.png"}.
formatYeslatex, typst or markdown.
sourceYesThe whole document, as text — for latex, the main .tex file.
contextNoExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelNoThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / assets / description
      Previous value: -"Files the source refers to by relative path, fetched before compiling (Typst only). Each {url, path}: a public https URL and the path the source uses, e.g. {\"url\": \"https://example.org/plot.png\", \"path\": \"figures/plot.png\"}."New value: +"Files the source refers to by relative path, fetched before compiling (latex or typst). Each {url, path}: a public https URL and the path the source uses, e.g. {\"url\": \"https://example.org/plot.png\", \"path\": \"figures/plot.png\"}."
    • addedInput schema / properties / files
      Added value: +{
      +  "description": "LaTeX only: the rest of the project beside the main file. Each {path, text} for a .tex, .bib, .cls or .sty, or {path, base64} for an image or other binary file. Paths are relative, as the source refers to them, e.g. chapters/intro.tex or figures/plot.png.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "base64": {
      +        "description": "The file's bytes, base64, for a binary file.",
      +        "type": "string"
      +      },
      +      "path": {
      +        "description": "Relative path inside the project.",
      +        "type": "string"
      +      },
      +      "text": {
      +        "description": "The file's text.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "path"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / format / description
      Previous value: -"typst or markdown."New value: +"latex, typst or markdown."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "typst",
      -  "markdown"
      -]New value: +[
      +  "latex",
      +  "typst",
      +  "markdown"
      +]
    • changedInput schema / properties / source / description
      Previous value: -"The whole document, as text."New value: +"The whole document, as text — for latex, the main .tex file."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the link lasts about six days, the PDF is stored in the account's own storage, the first compile of a rarely used package can take a minute, and compiler error messages are returned verbatim with the failing line. These are all actionable facts an agent needs that the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true) do not convey.

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 core action and output lead the paragraph, then format-specific detail follows in order. Every sentence carries operational weight (engine caveats, minted/biber limits, error behavior); nothing is filler despite the length, which is justified by three supported formats.

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 still explains the return value (a link, ~six-day lifetime) and failure mode (compiler message with failing line). Combined with format constraints and asset handling, an agent has everything needed to call this correctly, even at 7 parameters.

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 genuine meaning about how parameters interact: the main .tex goes in `source`, the rest of the project (chapters, refs.bib, .cls) goes in `files`, and images may be supplied either as base64 inside `files` or via `assets` URLs. That clarifies the files-vs-assets split beyond the schema text.

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 (compiles/renders), the resource (a document in LaTeX, Typst or Markdown), the output artifact (a PDF filed in account storage) and the return value (an openable link). An agent can instantly tell this apart from the workbook-centric siblings.

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 clear per-format context so the agent knows which value to pass: latex is real TeX with Tectonic, typst is a complete Typst document, markdown is a clean report style. It also states constraints (shell escape off, biber unavailable) that steer the agent toward valid inputs. No explicit exclusions are needed since no sibling performs a comparable compile.

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.