Skip to main content
Glama

Render a saved template

render_card

Render one of the user's saved templates with the given text and return the PNG (shown inline, at 1x). Needs an API key. On a paid plan the image is clean (no watermark); on the free tier it is watermarked. Each call spends one image of the monthly quota. Use it when the user wants the actual file, e.g. to host it themselves. For an og:image tag that needs no hosting, or for a 2x retina file, prefer og_image_url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoOutput canvas: og (1200x630), youtube (1280x720), square (1080x1080), portrait (1080x1350), story (1080x1920), pinterest (1000x1500). Defaults to the template's own size, usually og (1200x630, the link preview size). Layouts restack automatically on square and vertical canvases.
fieldsNoWhat to put on the card. Text fields replace the template's text; the *_url fields replace its pictures, fetched server-side. Omit a field to keep what the template has. Design - colours, fonts, layout, crop framing - never changes.
templateYesTemplate slug from list_templates or save_template.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / fields / description
      Previous value: -"Text to draw on the card. Omit a field to keep the template's own text. Design (colours, fonts, layout, photo) never changes."New value: +"What to put on the card. Text fields replace the template's text; the *_url fields replace its pictures, fetched server-side. Omit a field to keep what the template has. Design - colours, fonts, layout, crop framing - never changes."
    • addedInput schema / properties / fields / properties / background_url
      Added value: +{
      +  "description": "Absolute https URL of the background photo, on a template whose background is a photo. Works on every card kind.",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / image2_url
      Added value: +{
      +  "description": "Absolute https URL of the second capture, used only by the Product card's window-and-phone frame (the phone over the browser window's corner). It needs image_url too: on its own there is no window for the phone to sit over and nothing is drawn.",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / image_url
      Added value: +{
      +  "description": "Absolute https URL of the picture for the card's image slot - the product photo, the screenshot inside the frame, or the avatar on a Profile card. PNG, JPEG or WebP, up to 5 MB. Omit it to keep the template's own picture. Minimal cards have no image slot.",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / logo_url
      Added value: +{
      +  "description": "Absolute https URL of the corner logo, pinned above the text. Drawn by every card kind except Profile, whose own picture is the avatar.",
      +  "type": "string"
      +}
  2. Changed6 schema fields changed
    • addedInput schema / properties / fields / properties / badge
      Added value: +{
      +  "description": "Sale sticker in a corner of the card, Product cards only: \"-30%\", \"SALE\", \"2 FOR 1\" (up to 18 characters).",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / price
      Added value: +{
      +  "description": "Price headline under the pitch, Product cards only. Free text so it can read \"$29\", \"49 PLN\" or \"Free\" (up to 16 characters).",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / price_note
      Added value: +{
      +  "description": "Small print beside the price, Product cards only: a billing period, a former price or a shipping note (up to 40 characters).",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields / properties / price_was
      Added value: +{
      +  "description": "The price this one replaces, drawn struck through beside it, Product cards only (up to 16 characters).",
      +  "type": "string"
      +}
    • changedInput schema / properties / fields / properties / rating / description
      Previous value: -"Star rating, Testimonial cards only."New value: +"Star rating, Testimonial and Product cards only."
    • changedInput schema / properties / fields / properties / title / description
      Previous value: -"Headline. Up to 220 characters; long titles auto-shrink to fit. On Profile cards this is the person's name, on Testimonial cards the role."New value: +"Headline. Up to 220 characters; long titles auto-shrink to fit. On Profile cards this is the person's name, on Testimonial cards the role, on Product cards the product's name."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses key behavioral context: an API key is required, free-tier renders are watermarked, and each call consumes one image from the monthly quota. This is consistent with idempotentHint=false and adds actionable details not present in the schema or annotations.

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?

Every sentence earns its place: it covers function, output format, auth, quota, watermarking, and when to prefer an alternative. It is front-loaded with the core behavior and does not waste words.

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 a tool with a nested object, no output schema, and non-trivial quota implications, the description plus rich schema is complete. The agent learns the output format, the constraints, and the alternative, and the schema covers every parameter in detail.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already fully documents all three parameters, including the nested fields and enumerations. The description adds only general context like 'with the given text' and does not need to repeat parameter-level syntax.

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?

The description states a specific verb and resource: 'Render one of the user's saved templates with the given text and return the PNG'. It also distinguishes itself from sibling og_image_url by clarifying that render_card produces the actual file while og_image_url is for hosted tags.

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?

It explicitly says when to use this tool ('when the user wants the actual file, e.g. to host it themselves') and when not to ('For an og:image tag that needs no hosting, or for a 2x retina file, prefer og_image_url'). This gives the agent a clear routing decision.

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.