Skip to main content
Glama

Signed og:image URL

og_image_url
Read-onlyIdempotent

Build a signed image URL for a saved template with the given text, ready to put in a page's tag. Nothing is rendered now: the image is generated when a crawler fetches the URL, cached at the edge for a day, and each uncached fetch spends one image of the monthly quota. Needs an API key. This is the zero-infrastructure way to give every page its own card; use it in page templates, CMS hooks and static site generators. Returns the URL and the ready meta tag.

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.
scaleNo2 renders at twice the pixel size for high-DPI screens (a 1200x630 card becomes 2400x1260). Default 1.
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.5/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: the image is generated only when a crawler fetches the URL, results are cached at the edge for a day, each uncached fetch consumes one image of the monthly quota, and an API key is required. These details are not present in the annotations and materially affect whether an agent should call this tool.

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?

The description is three dense sentences that front-load the purpose, then add the critical behavioral details (deferred generation, caching, quota, auth) and end with the return value. Every sentence earns its place and there is no padding.

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?

Even though there is no output schema, the description states what is returned ('the URL and the ready meta tag'). The schema covers all parameters thoroughly, and the description supplies the operational context—API key, caching, quota, and rendering timing—needed to invoke the tool safely and understand its effects.

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%, with detailed per-field descriptions for template, size, scale, and fields. The description itself adds little parameter-level meaning beyond mentioning 'saved template' and 'given text,' so the baseline of 3 applies without needing extra compensation.

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: 'Build a signed image URL for a saved template... ready to put in a page's <meta property="og:image"> tag.' It also distinguishes itself from rendering tools by explicitly saying 'Nothing is rendered now' and by framing the output as a URL and meta tag, which separates it from siblings like render_card and preview_card.

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 concrete usage contexts: 'use it in page templates, CMS hooks and static site generators' and calls it 'the zero-infrastructure way to give every page its own card.' It does not explicitly list when not to use it or directly compare itself to alternatives like card_from_url or generate_meta_tags, so it stops short of a 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.