Skip to main content
Glama
Sign In

monity.ai

by ai.monity
OverviewDiscussionsAdmin

Create monitor

create_monitor

Watch a web page and alert the user when it changes: price drops, restocks, new posts or listings, status changes, competitor updates, any 'tell me when this page changes'. Creates a website monitor that keeps watching after this conversation ends: monity.ai checks the page on a schedule in its own cloud browser, keeps a full-page screenshot and a full HTML copy of the page for every check, and alerts only when the change matters (an AI summary says what changed). Subject to the account plan's monitor limit. compareType AUTO (default) covers most pages; VISUAL for pixel comparison, TEXT for keyword monitoring, HTML for markup diffs. To watch one element pass selector (a CSS selector). Express the full intent in one call: use notifyWhen for a natural-language alert condition ('price drops below $500'), or notifyConditions + outputExtractor/jsonPath for deterministic threshold alerts without AI.

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": {
      "websiteUrl": "<websiteUrl>"
    },
    "name": "create_monitor"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoMonitor name (defaults to the URL host/path)
labelsNoLabel names to file the monitor under (up to 10); existing labels with the same name are reused.
actionsNoOrdered list of interactions to perform before each check, e.g. [{"type":"CLICK","selector":"#accept-cookies"},{"type":"WAIT","value":1500},{"type":"CLICK","selector":".load-more"}]. Use this when the content to watch is behind a cookie banner, a tab, a "show more" control, or a dropdown. Max 20 steps. Script and JS/CSS injection steps are dashboard-only and rejected here.
jsonPathNoFor JSON API endpoints: JSONPath to the value to monitor, e.g. $.data.items[0].price. Starts with '$'.
keywordsNoTEXT monitors only: comma-separated keywords to watch for, e.g. "sold out, unavailable"
selectorNoCSS selector of ONE element to watch instead of the whole page (e.g. '.product-price' or '#stock-status'). Makes an element monitor that is found by this selector on every check; leave compareType unset.
frequencyNoMinutes between checks, as a string: '5', '15', '30', '60' (hourly), '180', '360', '720', '1440' (daily), '10080' (weekly), '302400' (monthly). Omit for the plan default. A frequency faster than the plan allows is raised to the plan minimum.
notifyWhenNoNatural-language alert condition evaluated by AI on every check, e.g. 'notify me when the price drops below $500' or 'alert when the Pro plan changes'. Mutually exclusive with notifyConditions.
websiteUrlYesAbsolute http(s) URL of the page to monitor
compareTypeNoComparison mode (default AUTO)
workspaceIdNoWorkspace to create the monitor in (from list_workspaces): one of the workspaces this connection may use. Defaults to the person’s personal workspace when they allowed it.
keywordsActionNoTEXT monitors only: alert when keywords are ADDED to the page (default) or REMOVED from it
outputExtractorNoHow to extract the monitored value from the page text: NUMBER pulls the first number (good for prices), REGEX applies outputExtractorPattern, NONE keeps the full text.
notifyConditionsNoDeterministic alert conditions on the extracted output (no AI credits). All conditions must pass. Requires the output to change. Mutually exclusive with notifyWhen. Not available for HTML monitors.
outputExtractorPatternNoRegular expression for outputExtractor: REGEX — bare pattern or /pattern/flags; the first capture group (or full match) becomes the monitored output, e.g. 'In stock: (\d+)'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, open-world, non-destructive write; the description adds substantive behavior: the monitor persists after the conversation, checks run in a cloud browser on a schedule, a full-page screenshot and full HTML copy are retained per check, and alerts are AI-summarized. It also discloses operational constraints — the account plan's monitor limit and the rule that a too-fast frequency is raised to the plan minimum.

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?

The purpose and the 'keeps watching after the conversation ends' payoff are front-loaded, and later sentences each carry a distinct decision (compareType, selector, notifyWhen vs notifyConditions). It is a single dense block rather than structured sections, and some framing language ('any tell me when this page changes') is decorative, but there is little true waste.

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

Completeness4/5

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

For a 15-parameter, high-complexity creation tool with no output schema, the description covers the main decision points and the lifecycle behavior an agent needs to set expectations. What is missing is modest: it does not say what is returned on success (e.g. a monitor id usable with get_monitor or run_monitor) or how plan limits surface as errors.

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 baseline is 3, but the description adds genuine meaning beyond the schema: it explains when each compareType mode applies (VISUAL = pixel, TEXT = keyword, HTML = markup diffs), that passing selector yields an element monitor and compareType should be left unset, and the AI-vs-deterministic tradeoff between notifyWhen and notifyConditions. It does not cover every parameter (actions, labels, workspaceId are left to the schema), so it is not a 5.

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?

The opening states a specific verb and resource — 'Creates a website monitor' — plus the concrete outcome ('alert the user when it changes') and examples of change types. It is clearly distinguished from siblings like update_monitor, delete_monitor, and run_monitor, which operate on monitors that already exist.

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?

Gives real selection guidance: 'compareType AUTO (default) covers most pages', 'use notifyWhen for a natural-language alert condition, or notifyConditions + outputExtractor/jsonPath for deterministic threshold alerts', and 'To watch one element pass selector'. It never names an alternative sibling tool (e.g. update_monitor for changing an existing monitor, list_workspaces for the workspace list is only implied via param text), so it stops short of a 5.

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

All monity.ai toolsInspect
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.

Resources