Skip to main content
Glama

Connect a monitor to an action

writ_wire_monitor

Wire a monitor's change event to an action: run a workflow, send notifications, or wake an AI agent to respond when a watched page changes.

Instructions

Wire a monitor's change_detected event to an action. action='workflow' runs a saved workflow when the monitored page changes; action='notify' sends a notification (provide channels + recipients the account has configured); action='ai_task' WAKES AN AI AGENT with a task prompt — the agent opens the monitored page in a cloud browser, sees what changed (diff + extracted values) and works the prompt autonomously (add channels/recipients to also get notified when it finishes). Use after writ_create_monitor to make the monitor DO something on change. A PRICE watch takes threshold: the action then runs ONCE, when a check reads a price at or below it (threshold_op picks the side) — not on every change. AUTO-BUY: action='workflow' with a checkout workflow and buy (payment {kind, ref} from writ_payment, approval, spend cap) makes it a purchase, always saved as a rehearsal (dry run) that stops before the order is placed; the user turns real purchases on in the Writ app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyNoaction='workflow' only: the workflow is a CHECKOUT and runs as a purchase. Always saved with dry_run on (a rehearsal that stops before placing the order), whatever is sent; the user arms real purchases in the Writ app. Cloud monitors only.
nameNoOptional automation name.
titleNo
actionYesWhat to do on a detected change.
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).
promptNoaction='ai_task': what the agent should do when the monitor fires, e.g. "Check whether the price dropped below $500 and summarize what changed". Supports {{placeholders}} like {{diff_snippet}} and {{extracted.price}}.
enabledNo
messageNoNotification body template (supports {{event.url}}).
channelsNoNotification channels, e.g. ["pushover","email"] — required for action='notify'; optional with action='ai_task' (finish alert).
workflowNoWorkflow to run (name) — required for action='workflow'.
entry_urlNoaction='ai_task': page the agent starts on (defaults to the monitored URL).
max_stepsNoaction='ai_task': cap on agent steps per wake (default 20, max 100).
thresholdNoPrice watch: act only when the watched price reaches this number (e.g. 477.04), once; by default at or below it (see `threshold_op`), and a price on the other side, or one the page no longer shows, does nothing. The monitor must read the price (a selector or extract, not a visual zone). Omit it for an alert on any change. Works for a desktop monitor too (`device`).
monitor_idYesMonitor id from writ_create_monitor.
recipientsNoNotification recipients, e.g. ["pushover:1"]. OMIT to reach EVERY enabled recipient on the channel — the answer names who the alert actually reaches, and warns when nobody is configured.
workflow_idNo
threshold_opNoWhich side of `threshold` fires: lte = at or below (default: "drops to 477.04" fires at 477.04), lt = strictly below ("below / under / less than"), gte = at or above, gt = strictly above (a rise alert). Pass what the user's words say.
ai_session_idNoaction='ai_task': re-run this saved AI session instead of (or as well as) a prompt.
cooldown_minutesNoaction='ai_task': minimum minutes between wakes (default 10; 0 disables).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=true); the description goes well beyond, disclosing that auto-buy is always saved as a dry-run rehearsal until armed in the app, that price thresholds fire once and require a selector/extract, and that ai_task wakes an autonomous agent. These are material behavioral facts not available in annotations or schema.

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-loaded with the core purpose, then mode behaviors, price watch, and auto-buy in a logical order with UPPERCASE emphasis on the riskiest mode. Dense but every clause is load-bearing; slightly long for a single description but not padded.

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 19-parameter, nested-object tool with no output schema, the description covers the routing logic across action modes, the price-watch constraint, and the auto-buy safety model, which is what an agent needs to invoke it correctly. Nothing critical is left unexplained.

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

Parameters5/5

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

With 84% schema coverage the baseline is 3, but the description adds real semantics: how action modes partition which params apply (channels/recipients for notify, prompt/workflow for others), the threshold single-fire semantics tied to threshold_op, and the buy/spend_cap defaulting behavior. This meaningfully exceeds the schema text.

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?

States a specific verb+resource ('Wire a monitor's change_detected event to an action') and immediately enumerates the three concrete action modes with their distinct behaviors. It is clearly distinguished from writ_create_monitor, which is named as the prerequisite sibling.

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?

Explicitly says 'Use after writ_create_monitor to make the monitor DO something on change,' and gives per-mode usage conditions (workflow vs notify vs ai_task), plus the price-watch single-fire rule and the auto-buy rehearsal rule. Alternatives and exclusions are stated, not inferred.

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