Skip to main content
Glama

Save a preset as a template

save_template

Copy a preset (optionally with the user's text as its new defaults) into the user's account as a saved template, so render_card and og_image_url can use it. Needs an API key. Do this once per design, not per image: afterwards every render only passes the text that changes. Returns the slug to use next and a link to fine-tune the design in the editor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoTemplate name (up to 80 characters); its slug is derived from it. Defaults to the preset's name.
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.

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.2/5.0
Behavior4/5

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

Annotations already indicate this is a mutating, non-idempotent action. The description adds useful behavioral context: API key requirement, return values, and the workflow warning that implies repeated saves are not needed. It does not contradict annotations, and it reveals the non-idempotent nature by telling the agent to save once per design.

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?

Four sentences, each earning its place: purpose, authentication, usage frequency, and return value. The most important information is front-loaded and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 fields object and no output schema, the description covers the key missing pieces: what the return value is, how to use it next, and the once-per-design pattern. The rich schema handles parameter-level detail, so only explicit error/limit behavior is absent.

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%, and each parameter is thoroughly documented in the schema. The description adds conceptual value by explaining that fields become the template's defaults and that the slug is returned, but it does not need to repeat schema details.

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 uses a specific verb and resource: 'Copy a preset ... into the user's account as a saved template'. It also names the downstream consumers (render_card and og_image_url), which clearly separates this tool from siblings like list_presets and list_templates.

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?

The description gives clear workflow guidance: 'Do this once per design, not per image: afterwards every render only passes the text that changes.' It explains why and when to call the tool, though it does not explicitly state exclusions or alternative tools.

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.