Skip to main content
Glama

Rendex: Rendering API for Images, PDFs & Content Extraction

Mint Hosted Render URL

rendex_render_link
Read-only

Use this when the user wants a reusable, HOSTED image URL — an og:image or a link to embed in an tag — rather than the image bytes. Do NOT use for a one-off inline screenshot (use rendex_screenshot). Renders a URL, raw HTML, or Markdown and gives back a signed, hosted, edge-cached image URL instead of the bytes — ideal for dynamic OG images: drop the URL into or an tag and Rendex serves a cached copy on every share. Takes the same options as rendex_screenshot, plus an optional expiresIn. Returns { url, expiresAt, format, cacheTtl } as JSON. Costs 1 render credit per fresh render; cached repeat hits don't re-charge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsNoCustom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB.
cssNoCustom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB.
geoNoISO 3166-1 alpha-2 country code for geo-targeted capture (e.g., 'US', 'DE', 'JP'). Renders the page as seen from that country. Pro/Enterprise only. Note: CSS/JS injection, cookies, element capture, dark mode, and some other features are not available with geo-targeting.
urlNoThe webpage URL to capture (a schemeless host like 'example.com' is accepted). Mutually exclusive with 'html' and 'markdown'.
dataNoKey-value data object for Mustache templating. When provided, the 'html' or 'markdown' string is rendered as a logic-less Mustache template before capture — {{var}} inserts HTML-escaped, {{{var}}} inserts raw, {{#items}}...{{/items}} iterates arrays, {{a.b}} accesses nested fields. Not valid with 'url'. Max 256KB serialized.
htmlNoRaw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images.
delayNoMilliseconds to wait after page load before capture (useful for JS-rendered content)
widthNoViewport width in pixels (320-3840)
deviceNoDevice preset that sets viewport, scale factor, and user agent in one shot. E.g. 'iphone_15' for a mobile screenshot. Overrides width/height/deviceScaleFactor/userAgent.
formatNoOutput format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival.png
heightNoViewport height in pixels (240-2160)
cookiesNoCookies to set before capture. Useful for authenticated pages. Max 50 cookies.
geoCityNoCity for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'.
headersNoCustom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding.
qualityNoImage quality 1-100 (JPEG/WebP only, ignored for PNG/PDF)
timeoutNoMaximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap.
blockAdsNoBlock ads and trackers before capture
darkModeNoEmulate dark color scheme (prefers-color-scheme: dark)
fullPageNoCapture the full scrollable page instead of just the viewport
geoStateNoState or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'.
markdownNoMarkdown to render to an image or PDF. Mutually exclusive with 'url' and 'html'. The server converts it to HTML before rendering. Great for reports, release notes, README snapshots, documentation cards.
pdfScaleNoPDF scale factor (0.1-2). Default: 1
selectorNoCSS selector of a specific element to capture instead of the full page. Useful for OG images, component extraction (e.g. '#hero', '.pricing-card')
expiresInNoSeconds until the signed URL expires (60–2592000). Defaults to the server's TTL.
pdfFormatNoPDF page size. Only used when format='pdf'. Default: A4
pdfMarginNoPDF page margins. Only used when format='pdf'. Accepts CSS values.
userAgentNoOverride the browser user agent string.
waitUntilNoPage readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness.networkidle2
bestAttemptNoIf true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout.
resizeWidthNoDownscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF.
pdfLandscapeNoPDF landscape orientation. Only used when format='pdf'.
resizeHeightNoDownscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF.
hideSelectorsNoCSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors.
waitForSelectorNoCSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded')
deviceScaleFactorNoDevice pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina.
blockCookieBannersNoHide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors.
blockResourceTypesNoBlock specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots.
pdfPrintBackgroundNoPrint background colors/images in PDF. Default: true

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint, openWorldHint, etc.), the description adds valuable behavioral details: it returns a signed, hosted, edge-cached URL; it costs 1 render credit per fresh render and cached hits don't re-charge; and it specifies the JSON return shape. These are meaningful traits not covered by annotations. It does not contradict the readOnlyHint because consuming credits is not a data mutation. A small gap: it doesn't detail caching invalidation or error cases, but the provided context is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary use case, then explains behavior and costs. It's a few sentences long and each sentence adds new information (when to use, when not, return shape, credit cost). It is efficient but not as tight as a two-sentence description, hence a 4 instead of a 5.

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?

Given the tool's complexity (38 params, nested objects, no output schema), the description covers the essential missing context: it explicitly states the return format { url, expiresAt, format, cacheTtl }, the credit cost, and the shared parameter base with rendex_screenshot. This compensates for the absent output schema. It could have mentioned error scenarios or additional limitations, but the inclusion of return shape and caching makes it sufficiently complete for an agent to use 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 coverage is 100%, so the baseline is 3. The description does little to explain individual parameters, only noting it shares options with rendex_screenshot and adds expiresIn. Since every parameter is fully described in the schema, the description doesn't need to add much; it does not actively reduce clarity.

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 purpose: it mints a reusable, hosted image URL rather than returning image bytes. It specifically says 'Use this when the user wants a reusable, HOSTED image URL — an og:image or a link to embed in an <img> tag' and contrasts with the sibling rendex_screenshot, making the tool's identity and differentiation unmistakable.

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?

Usage guidance is explicit: 'Use this when...' for hosted URLs and 'Do NOT use for a one-off inline screenshot (use rendex_screenshot).' It also mentions that it accepts the same options as rendex_screenshot plus expiresIn, giving clear context on when to choose this tool over its sibling. This is a model of when/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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with explicit 'use when' and 'do NOT use' guidance in descriptions. The rendering tools are differentiated by output type (screenshot/PDF, hosted URL, branded artifact, extracted text), and the watch tools follow a patterned CRUD/run/test structure, leaving no ambiguity.

Naming Consistency4/5

Most tools follow a 'prefix_verb' or 'prefix_verb_noun' pattern (e.g., rendex_screenshot, watch_create), but there are minor inconsistencies: 'render_artifact' lacks the 'rendex_' prefix, and 'watch_runs' is a noun rather than a verb. Overall, the names are still predictable and readable.

Tool Count5/5

With 13 tools, the server is well-scoped. It covers two domains—rendering (5 tools) and monitoring (8 tools)—without unnecessary overlap or excessive complexity. Each tool earns its place in the set.

Completeness5/5

The rendering side covers screenshots, PDFs, hosted URLs, branded artifacts, and content extraction. The watch side provides full lifecycle management (create, get, list, update, delete), plus immediate runs, run history, and testing. There are no obvious gaps or dead ends in user workflows.