CrawlForge MCP Server

track_changes

Monitor any URL for content changes over time, creating a baseline and comparing snapshots to detect diff alerts for pricing, regulations, or availability.

Instructions

Use this to monitor a URL for content changes over time - competitor pricing, regulation updates, product availability. Start with operation:"create_baseline", then periodically use operation:"compare" to diff; repeated compare calls on the same URL are expected. Supports webhooks and scheduled monitoring, and scheduledMonitorOptions.hosted:true runs the monitor on CrawlForge's servers with email and signed webhooks. Not for a one-off read (scrape). Cost: 3 credits. Example: track_changes({url: "https://example.com/pricing", operation: "create_baseline"})

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No	The URL to track changes for (optional for list_scheduled_monitors)
`html`	No	HTML content to compare against baseline
`content`	No	Content to compare against baseline
`operation`	No	Tracking operation to perform	compare
`user_agent`	No	Override the outbound User-Agent. CrawlForge identifies itself honestly by default; use this only for targets you have your own agreement with.
`queryOptions`	No	Query options for history and stats retrieval
`exportOptions`	No	Export options for change history data
`respect_robots`	No	Respect the target site's robots.txt (default: true). Setting this to false is honoured, returns a warning in the response, and is recorded against your API key — it is your decision, not a silent default.
`storageOptions`	No	Storage and history retention settings
`trackingOptions`	No	Options for how changes are tracked and compared
`alertRuleOptions`	No	Alert rule configuration for change notifications
`dashboardOptions`	No	Dashboard display options
`monitoringOptions`	No	Monitoring schedule and notification settings
`notificationOptions`	No	Notification configuration for webhooks, Slack and email (email is sent by hosted monitors only)
`scheduledMonitorOptions`	No	Scheduled monitoring: recurring compare + notify, optional plain-English goal

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv6.5.0Sep 10, 2026

addedInput schema / properties / monitoringOptions / default
```
Added value: +{}
```

changedInput schema / properties / notificationOptions / description

Previous value: -"Notification configuration for webhooks and Slack"New value: +"Notification configuration for webhooks, Slack and email (email is sent by hosted monitors only)"

addedInput schema / properties / notificationOptions / properties / email

Added value: +{
+  "properties": {
+    "enabled": {
+      "default": false,
+      "type": "boolean"
+    },
+    "includeDetails": {
+      "default": true,
+      "type": "boolean"
+    },
+    "recipients": {
+      "items": {
+        "format": "email",
+        "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "subject": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / queryOptions / default
```
Added value: +{}
```

addedInput schema / properties / scheduledMonitorOptions / properties / hosted

Added value: +{
+  "default": false,
+  "description": "Run the monitor on CrawlForge's servers: it fires from the hosted scheduler whether or not this process is alive and sends email and signed webhooks. Each check bills 3 credits per compared target from the account; blocked and errored targets are free. Default false = local, in-process.",
+  "type": "boolean"
+}

addedInput schema / properties / scheduledMonitorOptions / properties / name

Added value: +{
+  "description": "Display name for a hosted monitor (default: the URL host)",
+  "maxLength": 80,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / storageOptions / default
```
Added value: +{}
```
addedInput schema / properties / trackingOptions / default
```
Added value: +{}
```

addedInput schema / properties / trackingOptions / properties / excludeSelectors / default

Added value: +[
+  "script",
+  "style",
+  "noscript",
+  ".advertisement",
+  ".ad",
+  "#comments"
+]

Changed14 schema fields changedv6.0.0Sep 6, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / alertRuleOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / dashboardOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / exportOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / monitoringOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / notificationOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / notificationOptions / properties / slack / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / notificationOptions / properties / webhook / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / notificationOptions / properties / webhook / properties / headers / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / queryOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / scheduledMonitorOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / storageOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / trackingOptions / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / trackingOptions / properties / significanceThresholds / additionalProperties
```
Removed value: -false
```

Changed2 schema fields changedv5.4.0Aug 29, 2026

addedInput schema / properties / respect_robots

Added value: +{
+  "description": "Respect the target site's robots.txt (default: true). Setting this to false is honoured, returns a warning in the response, and is recorded against your API key — it is your decision, not a silent default.",
+  "type": "boolean"
+}

addedInput schema / properties / user_agent

Added value: +{
+  "description": "Override the outbound User-Agent. CrawlForge identifies itself honestly by default; use this only for targets you have your own agreement with.",
+  "type": "string"
+}

Changed1 schema field changedv5.0.4Aug 21, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv4.10.0Jul 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only disclose readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description supplements this with useful behavioral nuances: cost (3 credits), hosted CrawlForge servers with signed webhooks, and the expected pattern of repeated compare calls on the same URL. This goes beyond the annotation surface but does not detail side effects like state storage of baselines, which is part of the tool's open-world effect.

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

Conciseness5/5

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

It is only two sentences and still covers purpose, workflow, alternatives, cost, hosting option, and an example. Everything is relevant and tightly packed without redundancy; it reads like a well-specified instruction rather than an exhaustive manual.

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 is very complex (15 parameters, nested objects, numerous sub-options). The description gives a good high-level flow but does not describe return values (no output schema present) nor elaborate on each of the many parameter groups (e.g., queryOptions, storageOptions, alertRuleOptions). Since there is no output schema, the description is expected to explain what the tool returns, which is missing here. It does provide enough to decide when to use it, but not enough for full understanding of its behavior across all operations.

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 100%, so the schema carries all parameter descriptions. However the description adds a meaningful semantic: a clear workflow of operations (create_baseline, then compare) and a concrete example with url and operation. That enriches param selection beyond what the schema enum alone provides, so the description gives something extra.

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 the tool's specific verb (monitor) and resource (a URL), plus concrete purposes (competitor pricing, regulation updates, product availability) to distinguish from a one-off scrape. It explicitly says 'Not for a one-off read (scrape)', which differentiates it from sibling tools like scrape or fetch_url without needing to inspect them.

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?

It gives an explicit when-to-use pattern: 'Start with operation: create_baseline, then periodically use operation: compare' and adds a when-not ('Not for a one-off read (scrape)'). It also references the alternative `scrape` directly, qualifying as explicit alternative rejection and a clear usage flow.

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

track_changes

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools