Skip to main content
Glama

Preview a card from a preset

preview_card
Read-onlyIdempotent

Render a preset with the user's text and return the image (shown inline). Free, no API key; the preview carries a small betterimage.io watermark and does not touch any quota. Use it to show the user what their card will look like before they commit. For a clean image: save_template + render_card on a paid API plan, or the one-off clean download in the editor.

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.
presetYesPreset key from list_presets, e.g. "loud-pastel".

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 the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral context: it is free, requires no API key, carries a betterimage.io watermark, and does not touch any quota. It also states that the result is returned as an image shown inline. This is valuable context not present in the 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?

Three sentences with no filler. The core function is front-loaded, followed by key constraints (free, watermark, no quota), then a clear use case and alternative. Every sentence earns its place.

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?

The description covers the tool's purpose, output behavior, cost/watermark implications, quota impact, and the alternative clean-image flow. The schema already documents the preset parameter and field semantics, so nothing essential is missing for an agent to select and invoke this tool correctly.

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 fully documents all parameters, including the preset key and nested fields object. The description itself adds little parameter-level detail beyond 'with the user's text' and 'from a preset', but that is acceptable given the schema carries the load.

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 opens with a specific verb and resource: 'Render a preset with the user's text and return the image'. It also differentiates itself from render_card by framing this as a free, watermarked preview versus the 'clean image' path. This leaves no ambiguity about what the tool does.

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 states when to use this tool: 'Use it to show the user what their card will look like before they commit.' It also names alternatives for the clean-image case: 'save_template + render_card on a paid API plan, or the one-off clean download in the editor.' This gives clear when and when-not guidance.

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.