Skip to main content
Glama

Generate PDF

generate_pdf
Destructive

Render one branded PDF in a brand kit and save it to the user's files: any document the user describes, from an invoice or a statement to a one-pager, a proposal, a memo, a case study, an agenda or a report. Drafts are limited to 20 per day. Templates: 'invoice' takes items of description, quantity, unit_price, up to 30 plus props invoice_number, issued_on, due_on, bill_to, currency, tax_rate, notes; 'statement' takes items of description, date, amount, up to 30 plus props account, account_of, period_start, period_end, currency, opening_balance, notes; 'report' takes markdown or blocks plus props subtitle, author, dated; 'letter' takes markdown or blocks plus props recipient, dated, signoff; 'proposal' takes markdown or blocks plus props client, valid_until, prepared_by. A document template renders whatever markdown you give it, so an unfamiliar ask (a press release, a checklist, a brief) is still a report, letter or proposal with the right headings. Line item fields are all strings, and every date is YYYY-MM-DD. Write a document as markdown (headings, lists, tables) or as blocks, never both, and its first heading becomes the title unless you pass a title. Leave brand_kit_id out to use the space's default brand. Returns the artifact id and how many pages it came to. It costs 1 credit, or nothing on a Solo or Pro plan. Do not call this again to retry.

Input Schema

NameRequiredDescriptionDefault
pageNoPage size; left out it follows the brand kit.
itemsNoLine items, in the fields the template names.
propsNoText fields for the template, all strings.
titleNoThe document title. Optional.
blocksNoThe document body as blocks.
markdownNoThe document body as markdown.
footer_textNoThe footer line. Empty string for no footer; left out it is the brand name.
template_idYes
brand_kit_idNoA brand_kit_id from list_brand_kits.
page_numbersNo
saved_template_idNoA saved_template_id from list_templates; its inputs seed the ones you pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • addedInput schema / properties / saved_template_id
      Added value: +{
      +  "description": "A saved_template_id from list_templates; its inputs seed the ones you pass.",
      +  "type": "string"
      +}
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations by disclosing the 20-drafts-per-day cap, the 1-credit cost (free on Solo/Pro), the return values (artifact id and page count), and the retry prohibition. Those are the operational constraints an agent needs before invoking a write tool, none of which are in the annotation block.

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 action and scoped tightly to what matters, with no filler. The template enumeration is a dense run-on that would read better as a list, but every clause carries information an agent needs.

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?

For an 11-parameter tool with nested objects and no output schema, the description covers body format, template-specific inputs, defaults (brand kit, footer, title), cost, limits, and return values. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 82%, yet the description adds real meaning: which props each template consumes, the 30-item limit, that all line-item fields are strings, that dates are YYYY-MM-DD, that markdown and blocks are mutually exclusive, and that the first heading becomes the title. That is substantial semantics beyond the schema, especially for the undescribed template_id enum.

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?

Opens with a specific verb+resource ('Render one branded PDF in a brand kit and save it to the user's files') and enumerates the document types it covers, which separates it from siblings like generate_markdown or generate_og_image. An agent knows exactly what it gets back: a saved PDF artifact.

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 concrete selection guidance — which template handles invoices vs statements vs freeform docs, and how to handle an unfamiliar ask by routing it through report/letter/proposal. Adds a 'do not call this again to retry' rule. Missing an explicit contrast with the markdown-generation sibling, so not a full 5.

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.