Skip to main content
Glama

Render Resume PDF

render_pdf
Idempotent

Generate PDFs for base resumes or job applications from saved career data, with optional template and formatting choices you can save for later renders.

Instructions

Render a PDF. target_type is 'base_resume' (target_id=slug) or 'application' (target_id=application id). Optional template_id selects a template (either engine; must be 'ready'; omit for the default). Response reports resolved_template_id / resolved_engine (the template actually used); template_fallback=true only when an explicit template_id was passed and the resolved id differs — a substitution of the persisted choice is reported by render_note, never by the flag. render_note is non-null only when the backend has no TeX and a LaTeX template was rendered through a Typst template instead; it names both. Returns the render result incl. pdf_path (an application render also has copy_path: where the user finds the PDF in their resumes folder, null when off), plus a next key: for an 'application' render this is the terminal apply-readiness hint (autofill_ready, incomplete/blocking groups, a conditional browser-handoff offer); for a 'base_resume' render it is always null — a base-resume preview isn't part of the score->tailor->render arc, so there is nothing to offer.

Without keep, template_id is a one-off and the saved design is unchanged.
With keep=true the template_id and/or formatting are saved on the resume
first, its later renders use them, and the response adds kept
{template_id, formatting}: what the resume now keeps.

Input Schema

NameRequiredDescriptionDefault
keepNoTrue: before rendering, the template_id and/or formatting given are saved on this base resume or tailored resume, so its later renders use them, after an edit too; template_id must name a ready template. False (default): template_id is a one-off for this render, the saved design is unchanged, and formatting is refused.
target_idYes
formattingNoLook settings to keep (keep=true), one object of the template knobs: font_size (10|11|12), side_margins and top_bottom_margin (0.3-1.0 inches), line_spacing (0.9-1.4), section_spacing (0-14 pt), entry_spacing (0-10 pt), justify and hide_divider (true|false), bullet_icon ("bullet"|"dash"), header_align ("left"|"center"|"right"), date_format ("verbatim"|"short_month"|"long_month"|"numeric"), education_order ("degree_first"|"institution_first"), skills_layout ("inline"|"bulleted"), section_order (a list of summary, experience, projects, extra_sections, skills, education, certifications; the rest follow in the template's order). It replaces the resume's saved look settings: a knob left out takes the template's default (on a tailored resume, its base resume's setting first), and {} clears them. An unknown knob or a value out of range is a 400 and nothing is kept. get_base_resume returns a base resume's saved formatting and template_id.
target_typeYes
template_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.0
    • addedInput schema / properties / formatting
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Look settings to keep (keep=true), one object of the template knobs: font_size (10|11|12), side_margins and top_bottom_margin (0.3-1.0 inches), line_spacing (0.9-1.4), section_spacing (0-14 pt), entry_spacing (0-10 pt), justify and hide_divider (true|false), bullet_icon (\"bullet\"|\"dash\"), header_align (\"left\"|\"center\"|\"right\"), date_format (\"verbatim\"|\"short_month\"|\"long_month\"|\"numeric\"), education_order (\"degree_first\"|\"institution_first\"), skills_layout (\"inline\"|\"bulleted\"), section_order (a list of summary, experience, projects, extra_sections, skills, education, certifications; the rest follow in the template's order). It replaces the resume's saved look settings: a knob left out takes the template's default (on a tailored resume, its base resume's setting first), and {} clears them. An unknown knob or a value out of range is a 400 and nothing is kept. get_base_resume returns a base resume's saved formatting and template_id.",
      +  "title": "Formatting"
      +}
    • addedInput schema / properties / keep
      Added value: +{
      +  "default": false,
      +  "description": "True: before rendering, the template_id and/or formatting given are saved on this base resume or tailored resume, so its later renders use them, after an edit too; template_id must name a ready template. False (default): template_id is a one-off for this render, the saved design is unchanged, and formatting is refused.",
      +  "title": "Keep",
      +  "type": "boolean"
      +}
  2. First observedv0.11.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare non-readonly, non-destructive, idempotent, but the description adds substantial behavior beyond that: template_fallback only triggers on explicit template_id mismatch, render_note only on the Typst-substitution path, keep=true persists template/formatting, and the `next` key is null for base_resume renders. These are non-obvious side effects and flag semantics not derivable from annotations.

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-loads the render action and target_type semantics, then layers on fallback/keep details. It's dense and the `next`/render_note explanations run long, but nearly every clause carries decision-relevant information about flags the agent will encounter.

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 takes on return-value disclosure and does it thoroughly: resolved_template_id/resolved_engine, template_fallback, render_note, pdf_path, copy_path nullability, the `next` key's shape per target_type, and kept{template_id, formatting}. For a 5-param tool with a mutation mode, nothing an agent needs is missing.

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 only 40% — target_id, template_id, and target_type are undocumented in the schema — but the description compensates: target_id's meaning depends on target_type, template_id requires a ready template and defaults when omitted, and keep's persistence behavior is explained. Formatting knobs are already richly described in the schema, so the description doesn't need to repeat them.

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+resource ('Render a PDF') and immediately disambiguates the two modes via target_type ('base_resume' (target_id=slug) or 'application' (target_id=application id)). An agent can tell exactly what this produces and how the two target kinds differ 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?

Explains the when-conditions well: template_id must be 'ready', omit for default, and keep=true vs default one-off are spelled out, plus the base_resume render is framed as a preview outside the score->tailor->render arc. It stops short of routing to siblings like get_rendered_pdf or get_rendered_pdf_page_image, so there is no explicit alternative-naming.

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