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 periodically checks a page or sitemap 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 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

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.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it discloses the cost model ('free to call', 1 credit per completed run regardless of type or whether a change was detected), the default target_type, and the sitemap defaults/hard cap (5000 default, 10000 max). It omits auth requirements, failure behavior, and the cadence default, so it is not fully exhaustive.

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 action, then progressively details cost and mode semantics. Slightly redundant between the opening 'Create a website-change monitor' and the following 'Creates a monitor that...' sentence, but no sentence is wasted.

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 nested-object creation tool with a single required 'request' param and no output schema, the description covers the most consequential semantics (mode selection, cost, sitemap limits). It still leaves cadence_minutes, notification events/secret, and the shape of the returned monitor unspecified.

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 description coverage is reported at 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains what target_type values actually do, that include_patterns/exclude_patterns are shell-style globs matched against each URL's path, and that max_urls defaults to 5000 with a hard cap of 10000. cadence_minutes, notification, name, and enabled remain undocumented.

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 and resource ('Create a website-change monitor') and immediately qualifies the resource ('periodically checks a page or sitemap for changes and can notify a webhook'). This cleanly separates it from the sibling monitors_get/list/update/delete tools.

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 strong in-tool guidance: target_type defaults to 'page' (exact-fingerprint diff) and 'sitemap' watches for added/removed entries, so an agent can pick the right mode. It does not, however, route the agent against sibling tools (e.g. when to create vs update an existing monitor), leaving that to inference.

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