Rendex: Rendering API for Images, PDFs & Content Extraction
Server Details
Render HTML, Markdown, or any URL to images or PDF, plus reader-mode extraction. MCP-native.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- copperline-labs/rendex-mcp
- GitHub Stars
- 3
- Server Listing
- rendex-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 11 of 11 tools scored.
Tools are neatly separated into two groups: general rendering (rendex_extract, rendex_render_link, rendex_screenshot) and watch/monitoring (watch_create, watch_delete, etc.). Within each group, each tool has a distinct, non-overlapping purpose.
Tool names follow a consistent pattern: a prefix ('rendex_' or 'watch_') followed by a verb_noun (e.g., 'rendex_extract', 'watch_create'). The pattern is uniform across all tools.
11 tools is a reasonable number for the scope. The rendering set has 3 core tools, and the watch set has 8 tools covering CRUD and operations. Neither too sparse nor too heavy.
The rendering tools cover content extraction, OG image generation, and screenshots/PDFs. The watch tools provide full lifecycle management. One minor gap: there's no direct tool for getting raw bytes of a screenshot (only a signed URL from render_link), but overall the surface is comprehensive.
Available Tools
11 toolsrendex_extractAInspect
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. | |
| 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. | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before extraction | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| extractFormat | No | Output shape — markdown (default, LLM-friendly prose), json (structured fields: title/byline/excerpt/siteName/length), or html (cleaned reader-mode HTML). | markdown |
| hideSelectors | No | CSS selectors to hide (display:none) before extraction. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before extraction. A curated selector list, lighter than custom hideSelectors. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: runs Chromium render pass, executes JavaScript, strips nav/ads/boilerplate, returns title/byline/excerpt. It mentions handling SPAs and Cloudflare timeout cap. While it does not cover all edge cases (e.g., rate limits), it provides sufficient behavioral context for an AI agent.
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 three sentences, front-loaded with purpose, then technical behavior, then use cases. Every sentence adds essential information with zero fluff. It is appropriately sized for the tool's complexity.
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?
The description explains main behaviors and use cases but lacks details on return structure for each format (e.g., markdown vs HTML). No output schema exists, so the description should clarify output shape per format. It also omits error handling. Given the tool's 8 parameters and complexity, it is adequate but not fully complete.
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?
Parameter schema descriptions cover 100% of parameters, so the baseline is 3. The tool description adds high-level context (e.g., formats, device presets) but does not repeat parameter details. The description adds some value beyond the schema, but the schema already does the heavy lifting.
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 'Extract clean reader-mode content from any webpage as Markdown, JSON, or HTML.' It specifies the verb (Extract), resource (webpage content), and output formats. It distinguishes from the sibling tool 'rendex_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 suggests 'Great for feeding page content to an LLM, summarization, or RAG ingestion,' implying suitable use cases. It mentions handling SPAs that simpler readers miss, providing context for when this tool is better. However, it lacks explicit when-not-to-use guidance or alternative tool comparisons beyond the sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_render_linkAInspect
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 |
|---|---|---|---|
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| 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. | |
| url | No | The webpage URL to capture. Mutually exclusive with 'html' and 'markdown'. | |
| 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. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| 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. | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| width | No | Viewport width in pixels (320-3840) | |
| 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. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| height | No | Viewport height in pixels (240-2160) | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before capture | |
| cacheTtl | No | Seconds to cache the result in R2 storage (3600-2592000). Returns a signed URL for retrieval. Requires async=true. | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. | |
| 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. | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| 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') | |
| expiresIn | No | Seconds until the signed URL expires (60–2592000). Defaults to the server's TTL. | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| userAgent | No | Override the browser user agent string. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| webhookUrl | No | URL to receive a POST callback when async capture completes. Payload is HMAC-SHA256 signed. Requires async=true. | |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='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. | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool returns a signed URL, edge-cached, and the return JSON structure. It does not mention destructive actions, auth needs, or rate limits, but the core behavior is well-described and consistent with a read-only rendering service.
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 exceptionally concise—two sentences that front-load the core functionality and use case, then cover options and return structure. Every sentence adds value with no redundancy.
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 (41) and no output schema, the description adequately covers the core output and relationship to a sibling. It explains the cache behavior and primary use case, though it could mention async or error handling for full completeness.
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?
All parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds value by explaining the tool shares options with rendex_screenshot and by summarizing the return format (url, expiresAt, format, cacheTtl), which is not in the parameter 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 that the tool renders a URL, raw HTML, or Markdown into a signed, hosted, edge-cached image URL. It distinguishes itself from the sibling tool 'rendex_screenshot' by noting it returns a URL instead of bytes, and it specifies the ideal use case for dynamic OG images.
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 when to use this tool (for dynamic OG images) and mentions it takes the same options as rendex_screenshot, implying that for byte outputs one should use that sibling. However, it does not provide explicit when-not-to-use guidance or alternative tools beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_screenshotAInspect
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 |
|---|---|---|---|
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| 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. | |
| url | No | The webpage URL to capture. Mutually exclusive with 'html' and 'markdown'. | |
| 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. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| 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. | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| width | No | Viewport width in pixels (320-3840) | |
| 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. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| height | No | Viewport height in pixels (240-2160) | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before capture | |
| cacheTtl | No | Seconds to cache the result in R2 storage (3600-2592000). Returns a signed URL for retrieval. Requires async=true. | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. | |
| 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. | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| 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') | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| userAgent | No | Override the browser user agent string. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| webhookUrl | No | URL to receive a POST callback when async capture completes. Payload is HMAC-SHA256 signed. Requires async=true. | |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='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. | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the 'bestAttempt' mode for timeout behavior but lacks details on authentication, rate limits, error responses, or limitations. With no annotations, the description carries the full burden but is only partially transparent.
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 concise paragraph that covers the main capability without waste. It could benefit from structure (e.g., bullet points) but is efficient.
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?
The tool has 40 parameters, no output schema, and no annotations. The description fails to explain the return format (screenshot/PDF binary or URL) or prerequisites like authentication. This leaves significant gaps for agent understanding.
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 input schema already explains all 40 parameters. The tool description adds no extra semantic meaning beyond summarizing capabilities; 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 action 'Capture a screenshot or PDF' and the resources 'webpage, raw HTML, or Markdown'. It distinguishes from the sibling tool 'rendex_extract' by focusing on visual capture rather than extraction.
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 usage for capturing visual output but does not explicitly state when to use this tool versus the sibling 'rendex_extract' or when not to use it. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_createAInspect
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. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| 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. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: 'An active watch captures its baseline immediately,' the effect of paused mode ('no baseline capture or charge until resumed'), plan-dependent minimum intervals, and a constraint for visual-only mode with geo rendering. This goes well beyond basic creation.
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 well-organized, starting with purpose and then key details. It is not overly verbose, but at 3 sentences plus embedded examples, it could be slightly more concise. Still, it earns its place.
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 complexity (10 params, nested objects, no output schema), the description covers essential context: creation purpose, baseline behavior, plan restrictions, and return format. It does not mention error handling or auth, but overall it is adequate for agent invocation.
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 each parameter already has a detailed description. The tool description adds high-level context (e.g., 'Returns the created watch as JSON') but does not add meaning beyond the schema for individual parameters. Baseline 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 purpose: '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).' It specifies the resource (Rendex Watch) and the action (create), and distinguishes from sibling tools like watch_delete, watch_get, etc., by focusing on creation.
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 this tool (to create a new watch) and provides context about baseline capture and plan-dependent intervals. However, it does not explicitly contrast with alternatives (e.g., using watch_update to modify) or state when not to use it. This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_deleteAInspect
Delete a watch and its run history. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the irreversible nature ('Irreversible'), which is a key behavioral trait for a delete operation. However, with no annotations provided, it lacks details on required permissions, error handling, or consequences for dependent data, making it only moderately transparent.
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—two sentences, no wasted words. The first sentence states the action, and the second adds the critical behavioral note. It is well front-loaded and efficient.
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 one-parameter tool with no output schema and no annotations, the description covers the core action and irreversibility adequately. However, it omits what the tool returns (e.g., success indication) and any prerequisites, making it merely adequate for the complexity level.
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 already documents the single parameter 'id' with 100% coverage, describing it as a UUID. The description adds no additional meaning beyond the schema, matching the baseline score for high schema coverage.
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,' distinguishing it from sibling tools like watch_create, watch_get, and watch_list. The action is specific and unambiguous.
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 alternatives (e.g., watch_run or watch_test). It does not mention prerequisites or scenarios for deletion, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_getAInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns JSON with baseline image URL and status, which is helpful, but does not mention error behavior (e.g., what happens if the watch ID doesn't exist) or any side 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?
The description is a single, front-loaded sentence that immediately conveys the purpose. Every word earns its place with no 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 low complexity (one parameter, no output schema, no annotations), the description adequately covers what the tool does and what it returns. It could be improved by specifying the return format more explicitly, but it is complete enough for a simple get 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 description coverage is 100% for the single parameter 'id' with a clear description. The tool description adds no additional semantic value beyond the schema, 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?
The description clearly states 'Fetch one watch by ID', specifying the action and resource, and distinguishes from sibling tools like watch_list (multiple watches) and watch_create/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 implies usage for retrieving a single watch by ID but does not provide explicit guidance on when to use this tool versus alternatives (e.g., watch_list for multiple watches) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_listAInspect
List your watches (newest first), optionally filtered by status and paged. Returns { items, nextCursor }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (1–100). | |
| cursor | No | Pagination cursor from a previous nextCursor. | |
| status | No | Filter by status. | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so the description must disclose behavior. It mentions pagination via cursor and ordering (newest first), but omits potential side effects, authentication needs, or rate limits. The behavioral disclosure is minimal but not misleading.
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?
Single sentence, no redundant information. Front-loaded with key action and results. Every element earns its place.
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 no output schema, the return format is mentioned. The description explains filtering and pagination sufficiently. However, it does not clarify default filter behavior (e.g., status defaults to 'all'), though the input schema covers this. Nearly complete for a listing 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%, so the schema already explains all parameters. The description only restates that filtering and pagination are available, adding no new semantic value. Baseline 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 function: listing watches with filters and pagination, ordered newest first. It specifies the return shape '{ items, nextCursor }'. This distinguishes it from sibling tools like watch_get or watch_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 guidance on when to use this tool versus alternatives. While the context signals provide sibling names, the description does not mention when not to use it (e.g., for a single watch) or when alternatives are better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_runAInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the credit charge, that the run is queued (non-blocking), and the need to poll or use webhooks. It lacks details like idempotency or rate limits, but covers the essential behavioral traits for this simple 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?
Two sentences, no wasted words. All information is front-loaded and concise.
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 a simple tool with one parameter and no output schema, the description completely covers action, cost, return value, and next steps. No 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?
The schema provides 100% coverage for the only parameter (id) with a clear description. The tool description does not add further parameter semantics, so a baseline 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 action: 'Run an immediate check now' on a watch resource. It mentions the credit cost and distinguishes from sibling tools like watch_runs (for polling results) 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?
The description explicitly explains the tool triggers a run and directs to watch_runs for polling or a webhook for results. It implicitly distinguishes from alternatives but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_runsAInspect
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). | |
| limit | No | Page size (1–100). | |
| cursor | No | Pagination cursor from a previous nextCursor. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation (non-destructive) and mentions pagination and output format. However, with no annotations provided, the description carries the full burden. It lacks details on authentication requirements, rate limits, or what triggers errors, which would enhance transparency.
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, no redundancy. The key information (read, sorted, paged, output structure) is front-loaded. Every word contributes value.
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 (3 params, no output schema, high schema coverage), the description adequately explains the pagination, output fields, and core behavior. It could mention error conditions or required permissions, but is largely complete for a 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 baseline is 3. The description does not add additional semantic meaning beyond the schema's parameter descriptions for id, limit, and cursor. It mentions pagination cursor but does not elaborate on format or usage.
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 reads a watch's run history, sorted newest first, with pagination. It lists the specific fields returned (changed, diffScore, image URLs) and the output structure. This distinguishes it from siblings like watch_run (single run) and watch_get (watch details).
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. Siblings include watch_run (single run) and watch_list (list watches), but the description does not mention when to prefer run history over other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_testAInspect
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. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| 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. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it creates no watch, baseline, or diff, and returns JSON. Since no annotations are provided, the description carries full burden. It explains the dry-run nature and what is reported, but could mention error handling or failure modes.
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 (3-4 sentences), front-loaded with the main purpose, and contains no unnecessary information. Every sentence adds value.
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 objects, no output schema), the description is fairly complete: it states purpose, side effects, and return type. Could be improved by specifying the exact JSON structure, but it's sufficient for an agent to understand the tool's behavior.
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. The description does not add additional parameter explanations beyond what the schema already provides. The schema itself is detailed, so the description adds no extra value on parameters.
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 it is a dry-run of a watch config before creation, distinguishes from watch_create, and explains what it does (render config once, report captured data, reachability, text).
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 says 'before creating it' and 'validate a selector/scope/identity first', indicating when to use. Does not explicitly list alternatives but the sibling tools include watch_create, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_updateAInspect
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). | |
| paused | No | true to pause the watch, false to resume. | |
| diffMode | No | Change what counts as a change. | |
| aiSummary | No | Pro+ — toggle the AI 'what changed' summary (roadmap). | |
| threshold | No | Change the visual-change noise floor (0..1). | |
| 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. | |
| renderParams | No | Render knobs to deep-merge over the existing capture config. | |
| intervalMinutes | No | New check frequency in minutes (subject to your plan's floor). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: partial updates, deep-merge, re-baselining on scope changes, disclaimers for mailPro plan on notifyEmail. No contradictions.
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 succinct sentences front-loading purpose, then behavioral nuances. No redundancy. Every sentence earns its place.
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 11 parameters, a nested object, and no output schema, the description covers update semantics, deep-merge, re-baselining, and return value comprehensively.
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). Description adds global context: 'clears the baseline' for url, 'deep-merged over the existing config' for renderParams, and hints like 'Starter+' for webhookUrl. Adds value beyond individual parameter descriptions.
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 'Update a watch in place' with specific actions (pause/resume, re-point, change settings) and distinguishes from sibling tools like watch_create (create) and watch_delete (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?
Provides guidance on partial updates ('Only the fields you send change'), deep-merge behavior for renderParams, side effects of scope changes (re-baselines), and turning off channels via null values. Implicitly distinguishes from siblings but lacks explicit 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.