Someone types one sentence into Claude asking it to watch a page. The boring path is opening the PageCrawl dashboard, clicking "New monitor", filling the form. The better path is letting Claude make the call directly through the PageCrawl MCP server, with the right tracking mode, selector, frequency, and (now) page actions picked from your description. The same payloads work over the public REST API for anyone who prefers to script it from a shell instead.

This guide walks through five real prompts and the monitors Claude produces from them, simple to complex. The point is not that any of this is magic. It is that the MCP schema is detailed enough that Claude can read your sentence, pick the right tracking mode out of thirteen, build the selector or element array, and call add-page-monitor with the right shape. Every example below also shows the equivalent curl against the public API, hidden under a collapsed block so the post stays scannable.

If you have not connected the MCP server yet, the MCP launch post and the integration KB article cover setup for Claude.ai web, Claude Code, Cursor, and other MCP-compatible tools. This post picks up where those leave off.

Why this works at all

The MCP tool description that Claude reads for add-page-monitor is long on purpose. Every tracking mode (price, reader, fullpage, content_only, feed, specific_text, specific_number, json_path, ai_extract, seo, leaderboard, pdf_extract, http_status) carries one or two sentences explaining when to use it. That context is what lets the model pick correctly from a sentence of human input. It also documents the shape of the actions array (when interaction is needed), the elements array (when a tracking mode is too coarse for what you want), and the cross-workspace search behavior of every read tool. If you want to read the same prompt the model sees, it is the description field on the schema entries in app/Mcp/Tools/AddPageMonitor.php.

Paid plan note: read tools (list-monitors, get-changes-since, get-check-diff, get-monitor-history) work on the Free plan. Write tools, including add-page-monitor, require Standard or above. Free plan users can explore monitors through Claude but cannot create them via MCP.

Five real prompts, five real monitors

If you would rather wire this up from a script, every example below has a collapsed REST API equivalent right after the MCP snippet. Click "Doing the same thing without Claude" to expand it.

Price monitor in one sentence

You type: "Watch https://www.apple.com/shop/buy-mac/macbook-pro and tell me when the price changes."

Claude calls add-page-monitor with tracking_mode: "price". That mode auto-detects the price on the page and attaches an availability element alongside it, so you get both "price changed from X to Y" and "now out of stock" without saying so explicitly.

{
  "url": "https://www.apple.com/shop/buy-mac/macbook-pro",
  "tracking_mode": "price"
}

The monitor runs daily by default, captures a screenshot every check, and sends a notification when the price moves or the availability flips.

curl -X POST "https://pagecrawl.io/api/pages?api_token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.apple.com/shop/buy-mac/macbook-pro",
    "name": "MacBook Pro price",
    "frequency": 1440,
    "elements": [
      {"type": "price", "selector": "*", "label": "Price"},
      {"type": "availability", "selector": null, "label": "Availability"}
    ],
    "notifications": ["mail"]
  }'

Watching a legal page for changes

You type: "Send a weekly Slack message if Anthropic's consumer terms change at https://www.anthropic.com/legal/consumer-terms."

Claude picks tracking_mode: "reader". Reader mode runs a Readability-style extraction on the page, which strips the nav, header, footer, and the cookie banner so you do not get a notification every time the marketing site rotates a hero image. It also pulls the frequency from "weekly" (10,080 minutes) and the notification channel from "Slack".

{
  "url": "https://www.anthropic.com/legal/consumer-terms",
  "tracking_mode": "reader",
  "frequency": 10080,
  "notifications": ["slack"]
}

For other long-form legal and policy pages (privacy policies, terms, refund pages, cancellation flows), the help-center monitoring guide covers the broader pattern of treating these as competitive intelligence sources.

curl -X POST "https://pagecrawl.io/api/pages?api_token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.anthropic.com/legal/consumer-terms",
    "name": "Anthropic consumer terms",
    "frequency": 10080,
    "elements": [
      {"type": "fullpage", "selector": "article", "label": "Reader Mode"}
    ],
    "notifications": ["slack"]
  }'

Latest CVE timestamp from a JSON API

You type: "Track the timestamp of the latest CVE published in https://services.nvd.nist.gov/rest/json/cves/2.0?resultsPerPage=1, ping me hourly when a new one drops."

Claude picks tracking_mode: "json_path" (the URL is a JSON endpoint, not an HTML page) and writes the JSONPath expression from "the timestamp of the latest CVE published".

{
  "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?resultsPerPage=1",
  "tracking_mode": "json_path",
  "selector": "$.vulnerabilities[0].cve.published",
  "frequency": 60
}

The interesting thing here is that Claude does not need to know about the NVD response shape. It guesses a reasonable JSONPath from the phrase "latest CVE published", and you can correct it on the next turn ("the array is vulnerabilities, not cves") if you spot it before the first check.

curl -X POST "https://pagecrawl.io/api/pages?api_token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?resultsPerPage=1",
    "name": "NVD latest CVE timestamp",
    "frequency": 60,
    "elements": [
      {"type": "json_path", "selector": "$.vulnerabilities[0].cve.published", "label": "Latest CVE published"}
    ]
  }'

A JavaScript tracked element for a value buried in a data attribute

You type: "On https://podcastindex.org/podcast/12345 I want to track the value of data-listener-count on .episode-stats. Nothing else."

A plain CSS selector cannot reach a data attribute on its own. Claude drops out of the high-level tracking_mode and uses the raw elements array with a javascript element type. The selector field on a javascript element is the JS expression whose return value becomes the tracked content.

{
  "url": "https://podcastindex.org/podcast/12345",
  "name": "Podcast listener count",
  "elements": [
    {
      "type": "javascript",
      "selector": "document.querySelector('.episode-stats')?.dataset.listenerCount",
      "label": "Listener count"
    }
  ]
}

The CSS selector guide covers when to reach for a JS expression versus a selector, and the JavaScript Tracked Elements and Custom JavaScript Actions KB article has a longer list of patterns (regex extraction, JSON-LD parsing, multi-element aggregation).

curl -X POST "https://pagecrawl.io/api/pages?api_token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://podcastindex.org/podcast/12345",
    "name": "Podcast listener count",
    "frequency": 1440,
    "elements": [
      {
        "type": "javascript",
        "selector": "document.querySelector(\".episode-stats\")?.dataset.listenerCount",
        "label": "Listener count"
      }
    ]
  }'

Click the Pricing tab, wait for the prices to render, then track

You type: "On https://example-saas.com the headline price only appears after you click the Pricing tab. Click it, wait for the price block to load, then track the headline price."

Claude reaches for the actions array. The default actions for a new monitor are cookie-banner removal and overlay removal; passing an explicit actions array replaces those defaults, so Claude re-adds remove_cookies_v2 at the top of the sequence to keep the cookie wall out of the way. Then it clicks the tab, waits for the price element to appear (wait_element blocks for up to 15 seconds), and tracks the price text.

{
  "url": "https://example-saas.com",
  "tracking_mode": "specific_text",
  "selector": ".pricing-headline-price",
  "actions": [
    {"type": "remove_cookies_v2"},
    {"type": "click", "selector": "a[href='#pricing']"},
    {"type": "wait_element", "selector": ".pricing-headline-price"}
  ]
}

When the click and wait actions are not enough

For pages where the interaction is more involved (form-built React inputs, a confirm dialog you have to dismiss, content that lazy-loads on scroll), Claude can reach for the javascript action type. Write the code as a self-executed async arrow function so you can await between steps. The value field carries the code and is capped at 1500 characters.

{
  "url": "https://store.example.com/category",
  "tracking_mode": "specific_text",
  "selector": ".product-grid",
  "actions": [
    {"type": "remove_cookies_v2"},
    {
      "type": "javascript",
      "value": "(async () => { const sleep = ms => new Promise(r => setTimeout(r, ms)); document.querySelector('#load-more')?.click(); await sleep(800); document.querySelector('#load-more')?.click(); await sleep(800); })();"
    },
    {"type": "wait_element", "selector": ".product-grid"}
  ]
}

This clicks "Load more" twice, with a short wait between each click so the next batch of products has time to render. Native actions (click, wait_element, type, select) are still better for single-step interactions because the engine produces clearer logs. Reach for javascript when you need delays between steps, framework-aware event dispatching, or polling for an element that may take an unpredictable time to appear. The KB has the longer pattern guide with reusable helpers.

curl -X POST "https://pagecrawl.io/api/pages?api_token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example-saas.com",
    "name": "SaaS headline price",
    "frequency": 1440,
    "elements": [
      {"type": "text", "selector": ".pricing-headline-price", "label": "Headline price"}
    ],
    "actions": [
      {"type": "remove_cookies_v2"},
      {"type": "click", "selector": "a[href=\"#pricing\"]"},
      {"type": "wait_element", "selector": ".pricing-headline-price"}
    ]
  }'

Bonus: bulk setup and tagging in one message

You type: "Set up daily price-page monitors for these six competitor URLs and tag them all competitor-pricing: [list of URLs]."

Claude calls add-page-monitor six times in a row, each with tracking_mode: "price" and tags: ["competitor-pricing"]. This is where the MCP integration starts to feel worth it. Six form submissions in the dashboard becomes one chat message. If you later want to mute or delete the whole set, you can ask Claude to "pause every monitor tagged competitor-pricing" and it uses list-monitors + the right action in one turn.

The REST equivalent is a single call with track_type: "multiple" and a urls array, which is documented in the API quickstart.

After setup: the follow-up prompts that earn the integration

The creation prompts are the obvious win, but the ongoing read-side prompts are what actually compound. A few patterns we use daily:

• "What changed across all monitors in the last 24 hours, sorted by priority?" Claude calls get-changes-since with min_priority: 70 and reads back the AI summaries.
• "Show me the exact diff for the monitor on stripe.com pricing." Claude calls list-monitors to find the slug, then get-check-diff and paraphrases the result.
• "Force a recheck on the competitor monitors tagged competitor-pricing." Claude calls list-monitors with the tag filter, then loops through trigger-check per monitor.
• "Mark everything as seen, I am caught up." mark-changes-seen with no monitor_id does this in one call.

None of these are documented anywhere; the schema descriptions are detailed enough that Claude figures them out from the way you ask.

Claude web vs Claude Code: which to use for what

Claude.ai web is the right surface for one-off setup ("watch this page", "what changed this week", "force a recheck"), conversational triage, and sharing the result with a teammate via a chat link. The MCP server connects through OAuth the first time and stays connected.

Claude Code is the right surface when monitors are part of a larger development workflow. Examples that show up in practice: piping a CSV of URLs into a one-shot script that creates a hundred monitors with consistent tags, building a CLI playbook that adds a monitor + triggers an immediate check + waits for the result, or wiring the MCP server into a CI job that creates a monitor for every new deployment URL. Token-based auth in Claude Code makes this scriptable in a way that browser OAuth does not.

For background on hybrid workflows (assistant in the middle, dedicated monitoring on the side), the OpenClaw integration post covers the same shape applied to a different AI assistant.

Frequently asked questions

Does Claude need write permission to do all this? Read tools work on the Free plan; write tools (creating monitors, triggering checks, tagging, marking seen) require Standard or above. The MCP server returns a clear error when a Free plan user hits a write tool, with a link to upgrade.

Can Claude figure out tracking modes I have never used before? In our testing, yes. The mode descriptions in the schema are long enough that the model picks the right one from a sentence of context. If you want to override, name the mode explicitly: "use ai_extract with the prompt 'pull every new CVE name from the JSON'" wins over any inference.

What if a page needs a real login flow? Set up the authentication once in the PageCrawl dashboard under Authentications, then reference it when you create the monitor (the MCP does not expose authentication management, intentionally; sharing credentials over chat is a bad pattern). The dashboard-created monitor will use the saved authentication on every check.

Can I run this without OAuth? Claude Code uses token-based auth, which is the right shape for headless and scripted use. Claude.ai web uses OAuth. Both paths are covered in the MCP integration KB.

Does this work in Cursor, ChatGPT, Codex, and other MCP clients? Same MCP server, same tools, same schema. The conversation feel differs by client; the underlying capability does not.

Choosing your PageCrawl plan

PageCrawl's Free plan lets you monitor 6 pages with 220 checks per month, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value.

Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access.

At an engineering hourly rate, Standard at $80/year pays for itself the first time you catch a breaking API change, a deprecated endpoint, or a silent config change before it takes down production. 100 monitored pages is enough to cover the changelogs and docs of every third-party API your stack depends on. Enterprise at $300/year adds higher check frequency, 500 pages, and full API access. All plans include the PageCrawl MCP Server, which plugs directly into Claude, Cursor, and other MCP-compatible tools. Developers can ask "what changed in the Stripe API docs this month?" and get a summary pulled from your own monitoring history. Paid plans unlock write access so AI tools can create monitors and trigger checks through conversation, turning your tracked pages into a living knowledge base instead of a pile of alert emails.

Getting Started

The Free plan is enough to connect the MCP server, explore your existing monitors through Claude, and see whether the conversational shape fits how your team works. Sign up at pagecrawl.io/register, connect the MCP server in your client of choice (instructions here), and ask Claude to set up the first monitor. The write tools unlock automatically the moment you upgrade.