MCP-сервер для Rendex — создание скриншотов и PDF-файлов любых веб-страниц с помощью ИИ-агентов через протокол Model Context Protocol.
Добавьте в конфигурацию вашего MCP-клиента:
{
"mcpServers": {
"rendex": {
"command": "npx",
"args": ["-y", "@copperline/rendex-mcp"],
"env": {
"RENDEX_API_KEY": "your-api-key"
}
}
}
}Где добавить:
Клиент | Расположение конфигурации |
Claude Desktop |
|
Cursor |
|
Windsurf | Настройки > MCP Servers |
Добавьте .mcp.json в корень вашего проекта с той же конфигурацией, что указана выше. Затем перезапустите Claude Code.
Важно: Добавьте
.mcp.jsonв ваш.gitignore— он содержит ваш API-ключ.
Подключайтесь напрямую — установка не требуется (только для Claude Desktop):
{
"mcpServers": {
"rendex": {
"url": "https://mcp.rendex.dev/mcp",
"headers": {
"Authorization": "Bearer your-api-key"
}
}
}
}Related MCP server: RendShot MCP Server
rendex_screenshotСоздание скриншота или PDF-файла любой веб-страницы или необработанного HTML.
"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"Параметры:
Параметр | Тип | По умолчанию | Описание | |||
| string | обязателен* | URL веб-страницы для захвата. Взаимоисключающий с | |||
| string | — | Необработанный HTML для рендеринга. Взаимоисключающий с | |||
|
|
|
|
|
| Формат вывода |
| boolean |
| Захват всей прокручиваемой страницы | |||
| boolean |
| Эмуляция темной цветовой схемы | |||
| number |
| Ширина области просмотра (320-3840) | |||
| number |
| Высота области просмотра (240-2160) | |||
| number |
| Качество изображения 1-100 (только для JPEG/WebP, по умолчанию 80) | |||
| number |
| Задержка в мс перед захватом | |||
| boolean |
| Блокировка рекламы и трекеров | |||
| string[] | — | Типы блокируемых ресурсов: | |||
| number |
| Коэффициент масштабирования устройства (1-3). По умолчанию 2× Retina | |||
| number |
| Максимальное время ожидания загрузки страницы в секундах (5-60) | |||
| string |
| Готовность страницы: | |||
| string | — | CSS-селектор, который нужно дождаться перед захватом | |||
| boolean |
| Возвращать частичный рендер при тайм-ауте вместо ошибки | |||
| string | — | CSS-селектор элемента для захвата вместо всей страницы | |||
| string | — | Пользовательский CSS для внедрения перед захватом (макс. 50 КБ) | |||
| string | — | Пользовательский JavaScript для выполнения перед захватом (макс. 50 КБ) | |||
| array | — | Файлы cookie для аутентифицированных захватов (макс. 50) | |||
| object | — | Пользовательские HTTP-заголовки для запроса страницы | |||
| string | — | Переопределение строки user agent браузера | |||
| string | — | Размер страницы PDF: | |||
| boolean | — | Альбомная ориентация PDF | |||
| boolean |
| Печать фона в PDF | |||
| number |
| Коэффициент масштабирования PDF (0.1-2) | |||
| object | — | Поля PDF: | |||
| string | — | Код страны ISO для геотаргетированного захвата (Pro/Enterprise) | |||
| string | — | Город для геотаргетинга (требуется | |||
| string | — | Штат для геотаргетинга (требуется | |||
| boolean | — | Обработка асинхронно (возвращает ID задания) | |||
| string | — | URL для получения обратного вызова при завершении асинхронного захвата | |||
| number | — | Время кэширования результата в секундах (3600-2592000) |
Получите ваш API-ключ на rendex.dev.
Установите переменную окружения RENDEX_API_KEY в конфигурации вашего MCP-клиента.
План | Запросов/мес | Скорость |
Free | 500 | 10/мин |
Starter | 10,000 | 60/мин |
Pro | 100,000 | 300/мин |
Enterprise | Пользовательский | 1,000/мин |
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
