Rendex: Rendering API for Images, PDFs & Content Extraction

Create Watch

watch_create

Use this when the user asks to monitor, watch, or track a webpage for changes, or to be alerted/notified when a page changes. Creates a Rendex Watch — monitors a URL on a schedule and notifies 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "watch_create"
  }
}

Input Schema

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	How changes are detected. Default 'both' = a pixel diff (with a highlighted overlay) AND a FULL-PAGE text diff, alerting on either — catches any change, visual or text. 'visual' or 'text' narrow to one signal only.	both
`aiSummary`	No	Pro+ — attach a one-sentence AI 'what changed' summary to each detected change.
`threshold`	No	Visual sensitivity (0..1). Low (default 0.01) alerts on ANY change, including a small one on a long page (a changed-region test, not a whole-page pixel ratio). 0.06+ = only MAJOR visual changes (whole-page ratio). Text detection is unaffected.
`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), Basic 180, Starter 60, Pro 30, Enterprise 5.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 13, 2026

changedInput schema / properties / intervalMinutes / description

Previous value: -"Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Basic 180, Starter 180, Pro 30, Enterprise 5."New value: +"Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Basic 180, Starter 60, Pro 30, Enterprise 5."

Changed1 schema field changedAug 4, 2026

changedInput schema / properties / intervalMinutes / description

Previous value: -"Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5."New value: +"Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Basic 180, Starter 180, Pro 30, Enterprise 5."

Changed1 schema field changedJul 20, 2026

changedInput schema / properties / aiSummary / description

Previous value: -"Pro+ — attach an AI 'what changed' summary (roadmap)."New value: +"Pro+ — attach a one-sentence AI 'what changed' summary to each detected change."

Changed3 schema fields changedJul 15, 2026

changedInput schema / properties / diffMode / default
```
Previous value: -"visual"New value: +"both"
```

changedInput schema / properties / diffMode / description

Previous value: -"visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each."New value: +"How changes are detected. Default 'both' = a pixel diff (with a highlighted overlay) AND a FULL-PAGE text diff, alerting on either — catches any change, visual or text. 'visual' or 'text' narrow to one signal only."

changedInput schema / properties / threshold / description

Previous value: -"Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed."New value: +"Visual sensitivity (0..1). Low (default 0.01) alerts on ANY change, including a small one on a long page (a changed-region test, not a whole-page pixel ratio). 0.06+ = only MAJOR visual changes (whole-page ratio). Text detection is unaffected."

AddedJun 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish this as a non-read-only, open-world, non-idempotent, non-destructive write. The description adds behavior beyond them: an active watch 'captures its baseline immediately' (so creation has an immediate side effect and cost), and it returns the created watch as JSON, which matters because there is no output schema. It does not discuss plan quotas or rate limits beyond what the schema already states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: trigger condition first, then what the tool creates and how it detects changes, then the return shape. Nothing is repeated from the schema and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with a nested object and no output schema, the description covers the essentials: what is created, how changes are detected, that a baseline is captured immediately, and that the created watch is returned as JSON. Nothing an agent needs in order to call it correctly is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter (including the nested renderParams knobs, diffMode, threshold, intervalMinutes, notifyEmail) is documented in the schema itself. The description adds no parameter-level meaning beyond calling renderParams a subset of screenshot capture params. Baseline 3 is appropriate when the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Creates a Rendex Watch' that 'monitors a URL on a schedule and notifies when it changes', plus the diff mechanism (visual overlay, extracted-text diff, or both). That is far more than a restatement. It stops short of naming how it differs from close siblings like watch_test or watch_update, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It opens with an explicit trigger: 'Use this when the user asks to monitor, watch, or track a webpage for changes, or to be alerted/notified when a page changes.' That routes intent to this tool well. It does not mention alternatives (e.g., watch_test to trial a check, watch_update to change an existing watch) or when not to use it, so it is context-rich but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rendex: Rendering API for Images, PDFs & Content Extraction tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.