Skip to main content
Glama

Watch a page for changes

writ_create_monitor

Create a scheduled monitor to watch a URL for changes in page content, a CSS selector's text, or a visual zone, and fire a change_detected event. Returns a monitor id for alerts.

Instructions

Create a MONITOR — a target Writ checks on a schedule and that fires a change_detected event when the page, a CSS selector's text, or a visual ZONE of the page changes. Use when the user wants to WATCH a URL for changes/updates. Returns the monitor id for writ_wire_monitor. PROVE THE SELECTOR FIRST: open the page with writ_browser_use and pass its session_id — the selector is checked on the live page before saving. One that matches SEVERAL elements (Amazon '.a-price' matches a dozen; the check would join them into one blob) is pinned to the one shown; one that matches nothing or only an image becomes a VISUAL ZONE watch. NO SELECTOR FOUND AT ALL? mode='visual' + zone_text=<the value exactly as the page prints it, e.g. '51,77 EUR'> watches that area's pixels (digits are compared, so 51.77 finds '51,77 EUR'). A zone fires on ANY visual change — wire a change alert, not a threshold. selector_check in the answer says what was done. HOW OFTEN + ACCOUNT: no interval → needs_input (this plan's options + a tell_user to relay; nothing created); one the plan refuses is refused with the allowed ones. The page is read first: behind a sign-in → needs_persona; a bot check → it offers use_residential.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to monitor (required).
modeNo'visual' watches the on-screen ZONE of `selector`'s element (or of `zone_text`) and diffs its pixels — for charts, images, badges, or a value no selector can read.
watchNo'price' also rejects a selector whose text holds no number (it becomes a zone). Default 'content'.
deviceNoA linked Writ desktop's agent_id (writ_devices): act ON it. Omit to use the desktop this connection chose with writ_devices action='use' (if any).
enabledNoStart the monitor enabled (default true).
extractNoBROWSERLESS alternative to `selector`: a response-extraction spec the check applies to a plain HTTP response — {"from":"json","path":"data.price"} (a JSON/XHR endpoint, with request_url), {"from":"html_css","selector":".a-offscreen"} (the page markup), {"from":"regex","pattern":"..."} (a value in a script/JSON blob). PREFER it over `selector`/requires_browser whenever the value is readable without JavaScript — most prices and stock lines are: no browser at any check, cheaper, and harder to wall. Best first: structured data (an endpoint, JSON-LD, a JSON blob) survives a redesign. Same grammar as api_call response_extractions.
intervalNoHow often to check: an option id from the needs_input answer ('5m', '15m', '1h', '6h', '24h') or a number of seconds (3600). Omit it and the answer is needs_input: this account's options (checks a day, how long the check allowance lasts, allowed or which plan) and a tell_user to relay — ask the user, then call again with their pick. An interval the plan refuses is refused with the allowed ones; one that runs the allowance out before it renews is created with a `warning`.
selectorNoCSS selector for content-change monitoring; omit for uptime/status monitoring.
zone_textNoThe text the page PRINTS where the value is (e.g. '51,77 EUR', 'Currently unavailable'). Locates the zone when no selector exists.
persona_idNoEvery check carries this persona's LIVE session (kept fresh by the persona's own sign-in), so a login or a bot wall it passed stays passed (writ_personas). Only for a page behind a sign-in: a public page is watched without one, and the answer says when one is needed.
session_idNoAn open writ_browser_use session on this page. The selector is proved there before saving (pinned / switched to a zone); REQUIRED for mode='visual' or zone_text.
try_anywayNoAfter a bot-check answer: create it on Writ's servers anyway (a check that meets the bot check reads nothing).
request_urlNoWith `extract`: the endpoint the value comes from (an XHR the page calls), when it is not `url` itself.
use_residentialNoCheck through a residential exit — for sites that wall datacentre traffic (Amazon, marketplaces). A bot check found on the page is answered with this offer, or with the alternatives when the plan cannot pay for one.
interval_minutesNoLegacy: how often to check, in minutes. Prefer `interval`.
requires_browserNoRender with a real browser (JS) instead of plain HTTP. Set it for JS-rendered/SPA pages and framed pages (framesets/iframes): the check matches the rendered, frame-flattened DOM, and selector validation is deferred to the first browser render instead of a raw-HTML fetch. Omitted, a page the access check could only read in a browser is checked in one.
residential_countryNoISO-2 exit country for use_residential (e.g. 'ca'); implies use_residential.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, but the description goes well beyond: it explains the needs_input flow when interval is omitted, the needs_persona path for sign-in pages, the bot-check offer of use_residential, the refusal/warning outcomes for disallowed intervals, and the `selector_check` field returned. This is deep behavioral disclosure for a mutating, open-world tool.

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

Conciseness4/5

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

Front-loads purpose, then the selector-proof procedure, then frequency/account behavior; every section maps to a real prerequisite for a 17-parameter tool. It is dense and caps-heavy, and some interval semantics restate the schema, so it is efficient but not spartan.

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 17-parameter, open-world, non-idempotent creation tool with no output schema, the description covers the full lifecycle an agent needs: prerequisite session, selector validation, browserless alternative, scheduling/needs_input, auth/bot-wall handling, and the returned monitor id. Nothing required to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the per-parameter text already carries most semantics (baseline 3). The description adds cross-parameter workflow meaning the schema cannot convey: session_id must be supplied before saving, selector matching several elements gets pinned, mode='visual' requires session_id/zone_text, and extract/request_url may replace selector/requires_browser.

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

Purpose5/5

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

Opens with a specific verb+resource ('Create a MONITOR') and immediately defines the resource's scope: a scheduled target that fires a change_detected event on content, selector-text, or visual-zone change. It also names the sibling it hands off to (writ_wire_monitor) for alerting, so the agent can distinguish it from the rest of the browser/workflow family.

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

Usage Guidelines5/5

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

States explicitly when to use it ('when the user wants to WATCH a URL for changes/updates'), and routes specific situations to alternatives: writ_browser_use to prove the selector, extract over selector when the value is readable without JS, mode='visual' when no selector matches at all. The when-not guidance (extract preferred for browserless, no interval → needs_input) is unusually complete.

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