Skip to main content
Glama

betterimage.io

Check how a link previews

check_link_preview
Read-onlyIdempotent

Fetch a public page the way X, Facebook, LinkedIn, Slack and Discord crawlers do and report what they will show: the effective title, description and image per platform, the og:image's real format, dimensions and weight, and a list of concrete problems with fixes. Use when a user asks why their link looks wrong when shared, or before publishing. Only http(s) URLs on the public internet; one page fetch plus up to two image fetches per call. No API key needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page URL, e.g. https://example.com/post.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses the tool fetches external pages, limits fetches to one page and two images, and requires no API key. It also specifies the exact behavior of checking how crawlers see the page. No contradiction with 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?

The description is concise, with a clear structure: what it does, when to use, constraints. Every sentence adds value, front-loaded with the primary purpose.

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 without an output schema, the description lists the exact information returned (title, description, image per platform, og:image details, problems with fixes) and all constraints (public http(s), fetch limits). No missing information for an agent to decide to call it.

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 covers the only parameter (url) at 100%. The description does not add meaning beyond the schema; it only references the URL in context. Baseline 3 is appropriate.

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 clearly states the tool's function: fetching a page as social crawlers do and reporting the effective title, description, and image per platform, plus image details and problems. It distinguishes from siblings like preview_card or og_image_url by focusing on cross-platform preview analysis.

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?

Provides explicit usage context ('when a user asks why their link looks wrong when shared, or before publishing') and constraints (http(s), public, fetch limits). Does not mention alternatives or when-not-to-use, but the context is clear.

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.

Resources