The rendex-mcp server enables AI agents to capture screenshots and PDFs of webpages or raw HTML via the Rendex API.
Capture sources: Screenshot or generate PDFs from any URL or raw HTML (ideal for invoices, social cards, email templates, OG images)
Output formats: PNG, JPEG, WebP, or PDF with configurable quality
Rendering options: Full page or element-specific capture (CSS selector), customizable viewport, device pixel ratio (up to 3x Retina), and dark mode emulation
PDF configuration: Page size (A4, Letter, Legal, Tabloid, A3), orientation, margins, scale, and background printing
Page interaction: Inject custom CSS/JS (up to 50KB each), set cookies/headers, wait for selectors or page load events, add delays
Performance: Block ads, trackers, and specific resource types (fonts, images, media, stylesheets); set timeouts with optional best-attempt fallback for partial renders
Authentication: Pass cookies and custom HTTP headers for protected pages
Geo-targeting: Render pages as seen from specific countries/cities (Pro/Enterprise)
Async processing: Submit jobs asynchronously, poll by job ID, or receive results via webhook
Caching: Cache results from 1 hour up to 30 days
Custom user agent: Override the browser's user agent string
Allows capturing screenshots or PDFs of Amazon websites, including international domains like amazon.de, with support for geo-targeted captures from specific locations.
Enables capturing screenshots or PDFs of GitHub pages and repositories, with customization options for viewport size, dark mode, and full-page captures.
MCP server for Rendex — render raw HTML, Markdown, or any URL to an image or PDF via AI agents using the Model Context Protocol.
Add to your MCP client config:
{
"mcpServers": {
"rendex": {
"command": "npx",
"args": ["-y", "@copperline/rendex-mcp"],
"env": {
"RENDEX_API_KEY": "your-api-key"
}
}
}
}Where to add this:
Client | Config location |
Claude Desktop |
|
Cursor |
|
Windsurf | Settings > MCP Servers |
Add a .mcp.json to your project root with the same config above. Then restart Claude Code.
Important: Add
.mcp.jsonto your.gitignore— it contains your API key.
Connect to the hosted server at https://mcp.rendex.dev/mcp — no install needed.
It's fronted by OAuth 2.1 (authorization-code + PKCE S256), so OAuth-capable
clients (ChatGPT, Claude, Cursor, the MCP Inspector) connect with no API key —
you sign in with a one-time email code and each caller bills against their own
Rendex plan and credit pool.
Clients that prefer a static key can still pass one directly:
{
"mcpServers": {
"rendex": {
"url": "https://mcp.rendex.dev/mcp",
"headers": {
"Authorization": "Bearer your-api-key"
}
}
}
}Related MCP server: RendShot MCP Server
rendex_screenshotRender any webpage, raw HTML, or Markdown to an image or PDF.
"Take a screenshot of https://example.com"
"Capture the full page of https://news.ycombinator.com in dark mode"
"Generate a PDF of https://github.com with A4 page size"
"Capture https://amazon.de as seen from Germany"
"Render this HTML invoice as a PDF"
"Render this Markdown release note as a PDF"Parameters:
Parameter | Type | Default | Description |
| string | required* | Webpage URL to capture. Mutually exclusive with |
| string | — | Raw HTML to render. Mutually exclusive with |
| string | — | Markdown to render (server converts to HTML). Mutually exclusive with |
| object | — | Key-value data for Mustache templating. When set, the |
|
|
| Output format |
| boolean |
| Capture full scrollable page |
| boolean |
| Emulate dark color scheme |
| number |
| Viewport width (320-3840) |
| number |
| Viewport height (240-2160) |
| number | — | Downscale output to this width in px (aspect ratio preserved if |
| number | — | Downscale output to this height in px (aspect ratio preserved if |
| number |
| Image quality 1-100 (JPEG/WebP only, default 80) |
| number |
| Wait ms before capture |
| boolean |
| Block ads and trackers |
| boolean | — | Hide common cookie/consent banners (GDPR/CCPA) before capture |
| string[] | — | Block resource types: |
| string | — | Device preset: |
| number |
| Device pixel ratio (1-3). 2× Retina by default |
| number |
| Max seconds to wait for page load (5-60) |
| string |
| Page readiness: |
| string | — | CSS selector to wait for before capture |
| boolean |
| Return partial render on timeout instead of failing |
| string | — | CSS selector of element to capture instead of full page |
| string[] | — | CSS selectors to hide ( |
| string | — | Custom CSS to inject before capture (max 50KB) |
| string | — | Custom JavaScript to execute before capture (max 50KB) |
| array | — | Cookies to set for authenticated captures (max 50) |
| object | — | Custom HTTP headers for the page request |
| string | — | Override browser user agent string |
| string | — | PDF page size: |
| boolean | — | PDF landscape orientation |
| boolean |
| Print background in PDF |
| number |
| PDF scale factor (0.1-2) |
| object | — | PDF margins: |
| string | — | ISO country code for geo-targeted capture (Pro/Enterprise) |
| string | — | City for geo-targeting (requires |
| string | — | State for geo-targeting (requires |
| boolean | — | Process asynchronously (returns job ID) |
| string | — | URL to receive callback when async capture completes (Starter+; Free/Basic poll job status) |
| number | — | Seconds to cache result (3600-2592000) |
rendex_extractExtract clean reader-mode content from any webpage as Markdown, JSON, or HTML. Runs the same Chromium render pass as a screenshot, so it captures content after JavaScript runs — handling SPAs that fetch-only readers miss. Strips nav, ads, and boilerplate, returning the article body plus title, byline, and excerpt. Great for feeding page content to an LLM, summarization, or RAG ingestion.
"Extract the article text from https://example.com/post as Markdown"
"Pull the readable content from this SPA as JSON so I can summarize it"Parameters:
Parameter | Type | Default | Description |
| string | required | Webpage URL to extract readable content from |
|
|
| Output shape — |
| string | — | Device preset ( |
| boolean |
| Block ads and trackers before extraction |
| boolean | — | Hide common cookie/consent walls before extraction |
| string[] | — | CSS selectors to hide before extraction, e.g. |
| string |
| Page readiness: |
| number |
| Max seconds to wait for page load (5-60) |
rendex_render_linkRender a URL, raw HTML, or Markdown and get back a signed, hosted, edge-cached image URL instead of the bytes — ideal for dynamic OG images. Drop the URL into <meta property="og:image"> or an <img> tag and Rendex serves a cached copy on every share. Takes the same parameters as rendex_screenshot, plus an optional expiresIn. Returns { url, expiresAt, format, cacheTtl }.
"Make me a hosted OG-image URL for this Markdown release note"
"Give me a render link for this HTML card that I can drop into og:image"Parameter | Type | Default | Description |
(all | — | — | Same source ( |
| number | server TTL | Seconds until the signed URL expires (60–2592000) |
render_artifactTurn Markdown or HTML into a branded, downloadable artifact — a PDF, a PNG, and a hosted share page — in one call. Ideal for agent outputs: reports, invoices, summaries, release notes, dashboards. Apply a logo, accent color, font, header, and footer; choose PDF page size/orientation/margins. Returns hosted URLs { pdfUrl, pngUrl, shareUrl, expiresAt } — no storage needed on your side. Each requested format costs 1 render credit.
"Turn this Markdown report into a branded PDF and PNG with our logo and an orange accent"
"Render this invoice HTML to a PDF and give me a share link that expires in a week"Parameter | Type | Default | Description |
| string | required | The Markdown or HTML body to render (up to ~4MB) |
|
|
| How to interpret |
|
|
| Which formats to produce. Each costs 1 credit |
| string | — | CSS accent color for the bar, links, and headings (e.g. |
| string | — | http(s) URL of a logo image shown in the header |
| string | — | plain-text header line shown beside the logo |
| string | — | plain-text footer line shown at the bottom |
| string | — | CSS font-family stack for the body |
| object | — |
|
| object | — | Mustache data — when set, |
| number |
| Seconds until the hosted URLs expire (3600–2592000). Default 24h |
Monitor a URL on a schedule and get notified when it changes — real-Chrome visual diff (with a highlighted overlay), an extracted-text diff, or both. Eight tools let an agent set up, inspect, edit, and tear down watches on the shared Rendex platform (one rdx_ key, one credit pool).
"Watch https://example.com/pricing for visual changes and alert my webhook"
"Before I save it, test whether you can capture #pricing on that page"
"Show me the last few runs of watch <id> — did anything change?"Tool | Purpose | Key inputs |
| Create a watch (active → captures its baseline now) |
|
| Dry-run a config first (creates nothing) | same as |
| List your watches |
|
| Fetch one watch (+ baseline URL) |
|
| Run a check now (1 credit) |
|
| Run history with signed before/after/overlay URLs |
|
| Edit a watch in place — interval, diff mode, channels, render params |
|
| Delete a watch + its runs |
|
renderParams carries the per-check capture knobs (fullPage defaults to true, selector, device, geo (Pro+), plus noise controls ignoreRegions/ignoreText/minTextChars/suppressWhilePresent and uaMode). Interval floors are per-plan (Free 1440 / Basic 180 / Starter 60 / Pro 30 / Enterprise 5). Watch metadata + signed image URLs are returned as JSON text.
rendex_accountCheck the account from inside the agent: which plan it's on, how many render credits have been used this month vs. the limit (and when it resets), the per-minute rate limit, and a one-tap upgrade link. Lets an agent answer "how much have I used?" or "how do I get more renders?" without sending the user to the dashboard. Read-only — costs no credits.
"How many Rendex renders do I have left this month?"
"What plan am I on, and how do I upgrade for more?"Returns { plan, usage: { used, limit, remaining, unlimited, resetsAt }, rateLimitPerMinute, upgrade: { recommendedPlan, recommendedPlanCredits, upgradeUrl, manageBillingUrl } }.
Turn one reusable template into many documents. Pass a data object alongside html
or markdown, and Rendex renders the string as a logic-less Mustache
template before capture — {{var}} interpolation, {{#items}}…{{/items}} loops, and
nested {{a.b}} access. Great for invoices, reports, certificates, and OG cards.
"Render this HTML invoice template to a PDF, filling it with this data:
<h1>Invoice {{number}}</h1><p>Total: {{total}}</p>
data = { number: 'INV-014', total: '$2,400' }"data is valid only with html or markdown — combining it with url returns a
validation error.
Get your API key at rendex.dev.
Set the RENDEX_API_KEY environment variable in your MCP client configuration.
Plan | Calls/Month | Rate |
Free | 100 | 3/min |
Starter | 10,000 | 60/min |
Pro | 100,000 | 300/min |
Enterprise | Custom | 1,000/min |
MIT — Copperline Labs LLC
Extract clean reader-mode content from any webpage as Markdown, JSON, or HTML. Runs the same Chromium render pass as a screenshot, so it captures content after JavaScript runs — handles SPAs that fetch-only readers miss. Strips nav, ads, and boilerplate, returning the article body plus title, byline, and excerpt. Great for feeding page content to an LLM, summarization, or RAG ingestion.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The webpage URL to extract readable content from. | |
| extractFormat | No | Output shape — markdown (default, LLM-friendly prose), json (structured fields: title/byline/excerpt/siteName/length), or html (cleaned reader-mode HTML). | markdown |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| device | No | Device preset that sets viewport, scale factor, and user agent in one shot. E.g. 'iphone_15' to extract the mobile version of a page. | |
| blockAds | No | Block ads and trackers before extraction | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before extraction. A curated selector list, lighter than custom hideSelectors. | |
| hideSelectors | No | CSS selectors to hide (display:none) before extraction. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses that the tool runs a full Chromium render, captures after JavaScript execution (important for SPAs), strips nav/ads/boilerplate, and returns structured content. It also mentions Cloudflare's 60s hard cap on timeout. Missing explicit disclosure of potential failure cases or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences), front-loads the main action, and avoids unnecessary details. Every sentence adds value and contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should fully explain return values. It mentions returning article body plus title, byline, and excerpt but does not specify how these vary across formats (markdown, HTML). It also lacks details on error handling or behavior on failure, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 8 parameters, so baseline is 3. The description does not add significant parameter-level detail beyond what is already in the schema, though it provides context for how parameters like device and waitUntil affect rendering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts clean reader-mode content from any webpage, specifying output formats (Markdown, JSON, HTML) and the rendering process. It distinguishes from the sibling tool (screenshot) by focusing on content extraction rather than visual capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends the tool for feeding page content to LLMs, summarization, or RAG ingestion. It contrasts with fetch-only readers that miss SPAs, implying when this tool is preferable. However, it does not explicitly state when not to use it or provide direct comparison with the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a URL, raw HTML, or Markdown and get 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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The webpage URL to capture. Mutually exclusive with 'html' and 'markdown'. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| markdown | No | Markdown 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. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| width | No | Viewport width in pixels (320-3840) | |
| height | No | Viewport height in pixels (240-2160) | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| blockAds | No | Block ads and trackers before capture | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| device | No | Device 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. | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| selector | No | CSS selector of a specific element to capture instead of the full page. Useful for OG images, component extraction (e.g. '#hero', '.pricing-card') | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| resizeHeight | No | Downscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| userAgent | No | Override the browser user agent string. | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='pdf'. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| async | No | Process capture asynchronously. Returns a jobId immediately instead of waiting. Poll GET /v1/jobs/:jobId for status, or use webhookUrl for push notification. | |
| webhookUrl | No | URL to receive a POST callback when async capture completes. Payload is HMAC-SHA256 signed. Requires async=true. | |
| cacheTtl | No | Seconds to cache the result in R2 storage (3600-2592000). Returns a signed URL for retrieval. Requires async=true. | |
| data | No | Key-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. | |
| geo | No | ISO 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. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. | |
| expiresIn | No | Seconds until the signed URL expires (60–2592000). Defaults to the server's TTL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the output format and that the result is a signed URL served from edge cache. However, it does not disclose potential side effects, authentication requirements, rate limits, or what happens on errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is approximately four sentences, front-loaded with the core action and use case. Every sentence provides value, and the structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large parameter set (41) with 100% schema coverage and no output schema, the description explains the return format and references a sibling tool. It is mostly complete, though it could mention expected behavior for common edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds limited value beyond the schema. It provides a useful summary that the tool takes the same options as `rendex_screenshot` plus expiresIn, but does not add new parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a URL, raw HTML, or Markdown and returns a signed, hosted, edge-cached image URL. It distinguishes itself from the sibling tool `rendex_screenshot` by noting it takes the same options plus an optional expiresIn, and from `rendex_extract` by its different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is ideal for dynamic OG images and can be used in meta tags. It also notes it takes the same options as `rendex_screenshot`, implying that for raw screenshot bytes, one should use that tool. However, it does not provide explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture 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).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The webpage URL to capture. Mutually exclusive with 'html' and 'markdown'. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| markdown | No | Markdown 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. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| width | No | Viewport width in pixels (320-3840) | |
| height | No | Viewport height in pixels (240-2160) | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| blockAds | No | Block ads and trackers before capture | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| device | No | Device 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. | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| selector | No | CSS selector of a specific element to capture instead of the full page. Useful for OG images, component extraction (e.g. '#hero', '.pricing-card') | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| resizeHeight | No | Downscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| userAgent | No | Override the browser user agent string. | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='pdf'. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| async | No | Process capture asynchronously. Returns a jobId immediately instead of waiting. Poll GET /v1/jobs/:jobId for status, or use webhookUrl for push notification. | |
| webhookUrl | No | URL to receive a POST callback when async capture completes. Payload is HMAC-SHA256 signed. Requires async=true. | |
| cacheTtl | No | Seconds to cache the result in R2 storage (3600-2592000). Returns a signed URL for retrieval. Requires async=true. | |
| data | No | Key-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. | |
| geo | No | ISO 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. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosing behavioral traits. It mentions key behaviors like full-page capture, dark mode, ad blocking, bestAttempt (partial renders on timeout), async processing, and geo limitations. While it could detail error handling or authentication, the disclosure is comprehensive for a screenshot tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that lists features. It is not overly long but lacks a structured format (e.g., bullet points or clear sections). The first sentence captures the essence, but the rest reads as a feature dump. It is adequate but not optimally concise or front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (40), no output schema, and no annotations, the description covers the tool's scope well. It explains key behaviors like bestAttempt, async, and geo restrictions. However, it omits the exact return format (e.g., image data or signed URL) and may leave some details about parameter interactions implied. Still, it is fairly complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds value beyond the schema by summarizing high-level capabilities, noting mutual exclusivity among 'url', 'html', and 'markdown', and giving usage examples (e.g., 'Great for invoices, social cards'). This enriches the semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures screenshots or PDFs of webpages, raw HTML, or Markdown, listing many features. It uses a specific verb ('Capture') and resource, making the purpose unambiguous. Although it doesn't explicitly contrast with the sibling 'rendex_extract', the capabilities are distinct enough to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'rendex_extract'. It lacks explicit when-to-use or when-not-to-use advice, and no alternatives are mentioned. The context is clear for the tool itself, but the absence of comparative guidance reduces the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Rendex Watch — monitor a URL on a schedule and get notified when it changes (real-Chrome visual diff with a highlighted overlay, an extracted-text diff, or both). An active watch captures its baseline immediately. Returns the created watch as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to monitor (a schemeless host like 'rendex.dev/pricing' is upgraded to https). | |
| name | No | Optional label for the watch. | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| webhookUrl | No | Starter+ — HMAC-signed change-webhook target. | |
| notifyEmail | No | Any plan — send change alerts here. Must be your OWN account email (others are rejected). Defaults to it if omitted. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions baseline capture on creation and JSON return, but omits key behaviors like plan/rate limits, cost implications, authentication requirements, error handling, or what happens if the URL is invalid. The description is insufficient for a tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and purpose. Every sentence adds value, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested object, no output schema), the description is incomplete. It lacks operational details such as watch lifecycle, plan restrictions, usage limits, error handling, and how to manage the created watch. The schema covers parameter details, but the description does not provide enough context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters are well documented there. The description adds no additional meaning or context about parameters beyond summarizing the tool's overall function. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a Rendex Watch' to monitor a URL on a schedule and get notified when it changes. It specifies the diff modes (visual, text, both) and mentions immediate baseline capture and JSON return. This distinguishes it from sibling tools like watch_list or rendex_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (monitoring a URL for changes) but does not explicitly state when to use this tool versus alternatives like rendex_screenshot for one-off captures or watch_list for listing watches. It also lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a watch and its run history. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Irreversible' is a key behavioral trait, but it could mention permission requirements or cascading effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words, action front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with one parameter and no output schema, the description covers the action and irreversibility. Could mention error behavior or idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'id' parameter as a UUID. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a watch and its run history', which is specific and distinguishes from sibling tools like watch_create, watch_get, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies destructive usage with 'Irreversible' but does not explicitly state when to use or avoid this tool, nor compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one watch by ID, including its current baseline image URL and status. Returns JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Fetch' and 'Returns JSON', without clarifying read-only nature, idempotency, error handling, or any side effects. This is inadequate for a tool that could have network or permission implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence covering action, resource, and return type with no superfluous words. Every part adds value: verb, resource, included data, and format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is minimally adequate. It states what is returned but lacks details on the JSON structure, possible error responses, or performance considerations. The mention of 'baseline image URL and status' partially compensates for the missing output schema, but is not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'id' already described as 'The watch ID (UUID)'. The description adds no further meaning beyond restating 'by ID', so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one watch by ID', providing a specific verb and resource, and differentiates from sibling tools like watch_list (list) by focusing on a single watch retrieval. The inclusion of 'including its current baseline image URL and status' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you have a specific watch ID) but lacks explicit guidance on when not to use or comparison with alternatives. No mention of exclusions or preferred scenarios, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your watches (newest first), optionally filtered by status and paged. Returns { items, nextCursor }.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status. | all |
| cursor | No | Pagination cursor from a previous nextCursor. | |
| limit | No | Page size (1–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes ordering and pagination but does not explicitly state read-only nature or other behavioral traits like no side effects. Annotations absent, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no fluff. Front-loads action and result format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 3-param list tool with no output schema. Describes return structure but not individual item fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema by noting optional filtering and output structure ({ items, nextCursor }). Schema already covers param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List your watches' with ordering and optional filters. Distinguishes from siblings like watch_get (single) and watch_create (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives, but purpose is clear enough that an agent would infer when to list watches. Lacks guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an immediate check now (charges 1 credit). Returns the queued run; poll watch_runs for the result or receive a watch.changed webhook.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavior: charges 1 credit, returns a queued run (not final result), and directs to polling or webhook for results. Since no annotations provided, this covers essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action and credit cost, then result and follow-up options. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description fully covers what it does, cost, result format, and next steps, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description 'The watch ID (UUID)'. Description does not add extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs an immediate check (verb 'Run' + resource 'check now'), and specifies it charges 1 credit, distinguishing it from sibling tools like watch_runs which poll for results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (to run a check now) and mentions alternatives: poll watch_runs or receive a watch.changed webhook for results. No explicit 'when not to use' but sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a watch's run history (newest first), paged. Each run includes changed, diffScore, and signed before/after/overlay image URLs. Returns { items, nextCursor }.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). | |
| cursor | No | Pagination cursor from a previous nextCursor. | |
| limit | No | Page size (1–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses that the tool is read-only, returns paged results, and specifies the fields included in each run. However, it does not mention rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, comprising two sentences that front-load the main purpose and key details. Every sentence adds value, with no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains the return structure. It covers the primary use case and parameter roles. Minor gaps include lack of error handling or edge cases, but these are acceptable for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds context by explaining pagination flow (cursor and limit) and the role of the ID, but does not provide additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('read'), resource ('watch's run history'), ordering ('newest first'), and pagination. It distinguishes this tool from siblings like 'watch_list' (list watches) and 'watch_run' (trigger a run).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description does not mention prerequisites, such as requiring a watch ID, nor does it state when not to use it (e.g., for triggering a run).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a watch config BEFORE creating it — render the proposed config once and report what was captured + whether the page is reachable (and the text a text-watch would compare). Creates no watch, no baseline, no diff. Use this to validate a selector/scope/identity first. Returns JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to monitor (a schemeless host like 'rendex.dev/pricing' is upgraded to https). | |
| name | No | Optional label for the watch. | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| webhookUrl | No | Starter+ — HMAC-signed change-webhook target. | |
| notifyEmail | No | Any plan — send change alerts here. Must be your OWN account email (others are rejected). Defaults to it if omitted. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that no watch, baseline, or diff is created; reports captured content, reachability, and text for comparison. With no annotations, this provides essential behavioral info, though could mention resource consumption or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no unnecessary words. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Handles complexity of 10 params and nested objects well by summarizing output (JSON with capture and reachability). Lacks explicit field details but sufficient for a dry-run tool. No output schema to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond the schema; only reinforces validation purpose. No new parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it dry-runs a watch config before creation, emphasizing it does not create, baseline, or diff. It distinguishes from sibling tools like watch_create and watch_run by explicitly noting the dry-run nature and validation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using it before creating a watch to validate selectors/scope/identity. It does not contrast with all sibling tools, but the context (dry-run vs. actual creation) is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a watch in place — pause/resume (paused), re-point (url), change schedule/diff/notify settings, or turn a channel off (webhookUrl/notifyEmail = null). Only the fields you send change; renderParams is deep-merged over the existing config. A scope change (url/selector/fullPage/size/device) re-baselines on the next check. Returns the updated watch as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID) to update. | |
| url | No | Re-point to a new URL (clears the baseline; the next check re-baselines). | |
| name | No | Rename the watch (null to clear). | |
| intervalMinutes | No | New check frequency in minutes (subject to your plan's floor). | |
| diffMode | No | Change what counts as a change. | |
| threshold | No | Change the visual-change noise floor (0..1). | |
| renderParams | No | Render knobs to deep-merge over the existing capture config. | |
| aiSummary | No | Pro+ — toggle the AI 'what changed' summary (roadmap). | |
| webhookUrl | No | Starter+ — set or replace the change-webhook target; null to turn it off. | |
| notifyEmail | No | Set the alert email (your account email only); null to turn it off. | |
| paused | No | true to pause the watch, false to resume. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses in-place mutation, partial updates, deep-merge, re-baselining, and return value. Missing details on idempotency, rate limits, or permissions, but overall adequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused paragraph of four sentences. Every sentence adds value, no fluff, and the main purpose is front-loaded. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For 11 parameters with nested objects and no output schema, the description covers core behaviors, parameter effects, and return type. Lacks mention of error handling or watch existence checks, but is adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining effects like url clearing baseline, deep-merge of renderParams, and nullifying channels. It goes beyond schema definitions with practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Update a watch in place' and lists specific actions (pause/resume, re-point url, change schedule/diff/notify, turn off channel), clearly stating the verb and resource. It distinguishes from siblings like watch_create and watch_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains partial updates ('Only the fields you send change') and deep-merge behavior for renderParams, as well as re-baselining on scope changes. However, it does not explicitly contrast with watch_create or watch_get for read workflows, nor state prerequisites like watch existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.5.0rendex_render_linkwatch_createwatch_deletewatch_getwatch_listwatch_runwatch_runswatch_testwatch_updatev1.2.0rendex_extractrendex_screenshot9 fields changedInput schema / properties / blockCookieBannersAdded value: +{
+ "description": "Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors.",
+ "type": "boolean"
+}Input schema / properties / dataAdded value: +{
+ "additionalProperties": {},
+ "description": "Key-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.",
+ "type": "object"
+}Input schema / properties / deviceAdded value: +{
+ "description": "Device 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.",
+ "enum": [
+ "desktop",
+ "iphone_15",
+ "iphone_se",
+ "pixel_8",
+ "ipad",
+ "ipad_pro"
+ ],
+ "type": "string"
+}Input schema / properties / hideSelectorsAdded value: +{
+ "description": "CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+}Input schema / properties / html / descriptionPrevious value: -"Raw HTML to render and capture. Mutually exclusive with 'url'. Great for invoices, social cards, email templates, OG images."New value: +"Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images."Input schema / properties / markdownAdded value: +{
+ "description": "Markdown 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.",
+ "maxLength": 5242880,
+ "type": "string"
+}Input schema / properties / resizeHeightAdded value: +{
+ "description": "Downscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF.",
+ "maximum": 2160,
+ "minimum": 16,
+ "type": "integer"
+}Input schema / properties / resizeWidthAdded value: +{
+ "description": "Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF.",
+ "maximum": 3840,
+ "minimum": 16,
+ "type": "integer"
+}Input schema / properties / url / descriptionPrevious value: -"The webpage URL to capture. Mutually exclusive with 'html'."New value: +"The webpage URL to capture. Mutually exclusive with 'html' and 'markdown'."v0.1.1rendex_screenshot2 fields changedInput schema / properties / deviceScaleFactor / defaultPrevious value: -1New value: +2Input schema / properties / deviceScaleFactor / descriptionPrevious value: -"Device pixel ratio (1 = standard, 2 = retina)"New value: +"Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina."v0.1.0rendex_screenshotScored across 11 tools
The two tool families are clearly separated (rendering vs. watch management), and each watch operation has a distinct role. However, rendex_screenshot and rendex_render_link share nearly the same rendering pipeline and options, and watch_run vs. watch_runs differ by only one letter, so a couple of tools could still be misselected without careful reading.
All tool names use snake_case and a recognizable family prefix: rendex_* for rendering and watch_* for watch management. The imperative verb pattern is mostly consistent within the watch family, though watch_runs is a noun rather than a verb and rendex_screenshot reads as a noun, creating minor inconsistency.
At 11 tools, the surface is well-scoped and reasonable for the server's dual purpose: three rendering/capture tools and eight watch lifecycle tools. Each tool has a clear job, and none feel redundant or unnecessary.
The watch family is fully fleshed out with create, read, list, update, delete, test, run, and history operations. The rendering family covers capture, extraction, and hosted-link generation, which covers the apparent domain without obvious dead ends.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Generate images and PDFs from HTML/CSS, live websites, and reusable templates.
Screenshot any website with one API call PNG, JPEG, WebP, or PDF. Custom viewports, device emulation, ad blocking, dark mode, and smart caching.
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
