Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

monitors_create

Create a website-change monitor that checks a page or sitemap on a schedule and notifies a webhook when changes are detected.

Instructions

Create a website-change monitor. Creates a monitor that periodically checks a page or sitemap for changes and can notify a webhook. Free to call -- only completed check runs consume credits, at 1 credit per completed run regardless of target type or whether a change was detected. target_type defaults to "page" (exact-fingerprint diff of the scraped page). "sitemap" watches the sitemap at url for added/removed entries instead, honoring sitemap.include_patterns/exclude_patterns (shell-style globs matched against each URL's path) and sitemap.max_urls (default 5000, hard cap 10000).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYesMonitor definition

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / request / properties
      Added value: +{
+  "cadence_minutes": {
+    "type": "integer"
+  },
+  "enabled": {
+    "type": "boolean"
+  },
+  "name": {
+    "type": "string"
+  },
+  "notification": {
+    "properties": {
+      "events": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "webhook_secret": {
+        "type": "string"
+      },
+      "webhook_url": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "sitemap": {
+    "properties": {
+      "exclude_patterns": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "include_patterns": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "max_urls": {
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  "target_type": {
+    "enum": [
+      "page",
+      "sitemap"
+    ],
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}
  2. Addedv1.16.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description takes on the full burden of behavior disclosure. It goes beyond a simple 'create' by explaining the credit cost model (free to call, 1 credit per completed check run regardless of outcome) and the two target_type modes (page vs sitemap) with their filtering behavior. However, it does not disclose the response format or any prerequisites like authentication, so it is not fully transparent.

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 description is compact and front-loaded with the purpose, but it contains some redundancy: the first sentence 'Create a website-change monitor' is essentially restated by the second sentence 'Creates a monitor that periodically checks...' The rest of the description is dense and efficient, providing cost and parameter details without fluff.

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

Completeness3/5

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

The tool has a nested request object and no output schema or annotations, creating a need for the description to clarify request construction and return values. It thoroughly explains the target_type and sitemap options, but it does not state which fields are required (e.g., url) or what the tool returns upon success, leaving an agent to rely on assumptions. This is a notable gap for a creation endpoint.

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?

The input schema only describes the top-level `request` object and leaves nested fields undocumented. The description enriches the semantics by explaining the `target_type` default, the sitemap include/exclude patterns, and `max_urls` limits with defaults and caps. It does not add meaning for `url`, `name`, `enabled`, `notification`, or `cadence_minutes`, but those names are fairly self-explanatory.

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 description states a specific action ('Create a website-change monitor') and explains what it does: periodically checks a page or sitemap for changes and can notify a webhook. This clearly distinguishes it from sibling tools like monitors_list, monitors_get, monitors_delete, and monitors_update, which operate on existing monitors.

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

Usage Guidelines3/5

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

The description implies this tool is for creating new monitors, but it does not explicitly state when to use it versus alternatives. It does not mention that monitors_update is for modifying existing monitors or that monitors_checks is for viewing check runs, leaving the routing to inference from the tool name and sibling names.

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

Deploy Server

Other Tools