rendex-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RENDEX_API_KEY | Yes | Your Rendex API key for authentication. Get your API key at https://rendex.dev. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rendex_screenshotA | 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). |
| rendex_extractA | 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. |
| rendex_render_linkA | 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. |
| watch_createB | 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. |
| watch_testA | 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. |
| watch_listA | List your watches (newest first), optionally filtered by status and paged. Returns { items, nextCursor }. |
| watch_getA | Fetch one watch by ID, including its current baseline image URL and status. Returns JSON. |
| watch_runA | Run an immediate check now (charges 1 credit). Returns the queued run; poll watch_runs for the result or receive a watch.changed webhook. |
| watch_runsA | Read a watch's run history (newest first), paged. Each run includes changed, diffScore, and signed before/after/overlay image URLs. Returns { items, nextCursor }. |
| watch_deleteA | Delete a watch and its run history. Irreversible. |
| watch_updateA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.