Skip to main content
Glama

betterimage.io

by io.betterimage
OverviewDiscussionsAdmin

Card from a page URL

card_from_url
Read-onlyIdempotent

Make a social card for a page that already exists, in one call: fetches the page like a crawler, takes its title, description, author, domain and site icon, picks the starter design that fits the page (a Jev decision over every preset, about 100 ms) and returns the image (shown inline, watermarked, free). Use this first when the user gives a URL: "make an OG image for my latest post". Any field you pass overrides what the page says. Pass preset (see list_presets) to choose the design yourself, or a size. No API key needed; one page fetch plus one render per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page URL, e.g. https://example.com/blog/my-post.
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.
presetNoPreset key from list_presets. Omit it to let Jev pick the design that fits the page (the result names the pick and its runners-up). Fallback when no pick is possible: og-essay-light.

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.6/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and openWorld hints, but the description adds valuable behavioral detail: it fetches the page like a crawler, Jev decides over every preset in about 100 ms, the image is watermarked/free, no API key is needed, and passed fields override page content. This goes well beyond the structured hints.

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 dense but every sentence earns its place: core function first, then behavior, then usage direction, then override semantics, then fallback. The quoted user request and the list_presets pointer are functional, not 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?

There is no output schema, but the description explains the return value is an inline watermarked image and covers the fetch/render pipeline, no-auth requirement, and one-call behavior. The rich input schema covers the parameters; the only notable gap is what happens when the page fetch fails, which is not essential for tool selection.

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

Parameters4/5

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

Schema coverage is 100% with detailed per-field descriptions, including card-type restrictions and the image2_url dependency. The prose adds cross-cutting meaning: any passed field overrides what the page says, preset and size are alternative design controls, and the fallback is og-essay-light.

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 action and resource: 'Make a social card for a page that already exists, in one call.' It explains the full pipeline — fetching the page, extracting title/description/author/domain/icon, picking a design, and returning the image — which clearly distinguishes it from siblings like list_presets or render_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?

It gives explicit when-to-use guidance: 'Use this first when the user gives a URL' with a concrete user phrasing example. It does not explicitly name sibling tools as the when-not alternatives, though it does point to list_presets for overriding the design choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All betterimage.io toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources