Skip to main content
Glama

Rendex: Rendering API for Images, PDFs & Content Extraction

Capture Screenshot or PDF

rendex_screenshot
Read-only

Use this when the user asks to screenshot, capture, or take a picture of a webpage/URL, or to render raw HTML or Markdown to an image or PDF. Do NOT use to get a reusable hosted image URL (use rendex_render_link) or to make a branded multi-format document (use render_artifact). Captures a screenshot or PDF of any webpage, raw HTML, or Markdown. Supports full-page capture, dark mode, ad blocking, custom viewports, CSS/JS injection, cookie/header injection, PDF output, HTML and Markdown rendering, and progressive fallback for heavy sites. Returns partial renders on timeout by default (bestAttempt mode). Costs 1 render credit per call. Cookie/header injection requires Starter+; geo-targeting requires Pro+.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral detail beyond that: it returns partial renders on timeout by default, costs 1 render credit, uses progressive fallback for heavy sites, and requires specific plans for certain features (Starter+ for cookie/header injection, Pro+ for geo-targeting). No contradiction with annotations exists.

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 compact yet information-dense: it front-loads the trigger condition, then gives exclusions, a capability list, then behavior, cost, and access restrictions. Each sentence earns its place, and the structure guides the reader from selection to execution.

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?

Despite having 37 parameters, no output schema, and considerable complexity, this description covers selection criteria, sibling distinctions, key behaviors (bestAttempt, fallback), cost, and plan limitations. The only minor gap is the exact output delivery format, but the tool title and phrasing ('captures a screenshot or PDF') make the return type sufficiently clear for an agent to select and invoke the tool.

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?

The input schema has 100% parameter coverage with rich per-property descriptions (e.g., Mustache templating for 'data', 'waitUntil' semantics, PDF margin details). The description adds only a high-level capability summary without introducing parameter-level meaning beyond what the schema already provides, so the baseline score of 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 opens with explicit trigger phrases ('screenshot, capture, or take a picture of a webpage/URL') and clearly states the tool 'Captures a screenshot or PDF of any webpage, raw HTML, or Markdown.' It also names sibling tools (rendex_render_link, render_artifact) and explains exactly what this tool is NOT for, making distinction among siblings unambiguous.

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?

The description provides explicit when-to-use guidance ('Use this when the user asks to...') and when-not-to-use guidance with named alternatives ('Do NOT use to get a reusable hosted image URL...'). It also gives operational context: cost per call, plan requirements for cookie/header injection and geo-targeting, and the default bestAttempt fallback behavior.

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.