Skip to main content
Glama

Generate PDF

generate_pdf

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

TableJSON 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
Behavior4/5

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

Annotations only declare readOnlyHint=false, so the description carries the real burden and does it well: 20 drafts/day cap, 1 credit (free on Solo/Pro), default brand kit behavior, and the artifact id + page count return. It stops short of stating auth requirements or whether drafts are queued vs synchronous.

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?

Every sentence is informative and the scoping/cost facts are front-loaded, but the template enumeration compresses into a single dense paragraph that is hard to scan. Slightly more structure would improve it without adding length.

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 mutation tool with no output schema, the description covers the template contract, body-format rules, defaults, cost, rate limits, and return values. An agent has everything needed to construct a valid call without further inference.

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 82%, but the description adds substantial meaning beyond it: per-template line-item fields and their 30-item cap, that all line-item fields are strings, the YYYY-MM-DD date rule, the 'markdown or blocks, never both' exclusive-usage rule, and how the first heading becomes the title unless title is passed.

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 ('Render one branded PDF in a brand kit and save it to the user's files') and enumerates the concrete document types it covers. It clearly separates itself from siblings like generate_markdown and generate_image_background by naming the branded-PDF artifact and its templates.

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?

Gives explicit when-to-use routing for each template ('invoice' takes items..., 'report' takes markdown or blocks...) plus fallback guidance for unfamiliar asks ('a press release... is still a report, letter or proposal'). It also adds a hard exclusion – 'Do not call this again to retry' – and states the daily limit and cost.

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.