Guide

How to monitor websites from Claude Code, Cursor, or VS Code with MCP

Connect Page Deltas MCP to Claude Code, Cursor, or VS Code. Create AI-filtered website monitors from your agent. Free plan, no card.

Tell Page Deltas what matters

alert me when the Hubspot pricing changes

https://www.hubspot.com/pricing
HubSpot pricing page — Professional plan starting at €792/mo
PDPage DeltasAppnow

🔔 Change detected on https://www.hubspot.com/pricing:
Price of the Professional plan went up from €749/mo to €792/mo.

You ask Claude Code to watch a competitor's pricing page and ping you when the Pro tier moves. It writes a tidy polling script, runs once, and stops when the session ends. Next morning the page has changed and nobody got a message. The agent can reason about the page. It can't stay awake for you.

Coding agents need a durable monitor outside the chat: something that keeps checking after the session closes, filters noise with a brief, and surfaces changes when you ask. That is what the Page Deltas MCP server is for. I work on Page Deltas, so keep that in mind as you read. This post walks through connecting Claude Code, Cursor, VS Code Copilot, and Claude Desktop, then shows the prompts that create useful monitors.

A one-off fetch in the agent is fine for "what does this page say right now." It fails for "tell me when this page changes next week." You end up maintaining a cron job, a scraper, and a place to store the last snapshot. Most of that work isn't product work. It's babysitting.

An MCP-connected change monitor flips the split. The agent creates the watch and writes the brief. Page Deltas fetches the public page on an adaptive schedule, compares it to the last check, and only alerts when the change matches what you asked for. History and screenshots stay in your org. When you open a new chat, you ask the agent to list recent changes instead of rebuilding the poller.

Two details matter for agents. Checks aren't metered on Page Deltas, so a busy week of check_monitor_now calls doesn't burn a monthly quota. And cookie login sessions aren't accepted on the MCP endpoint. You authenticate with a Bearer API key, the same keys the REST API uses.

If you want the same operations from curl or Python instead of an agent, see how to turn any website into a change API. The general product walkthrough lives in how to monitor website changes.

Connect Claude Code, Cursor, or VS Code

Create a free account, then open Settings and API keys. You need an editor or admin role. Copy the key when it appears. It's shown once. Store it in an environment variable or your client's secret store, not in a committed config file. Keys look like pdt_… and act with admin-level access inside the organisation that created them.

Point any MCP client that supports remote Streamable HTTP at https://api.pagedeltas.com/mcp and pass the Authorization header on every request.

For Claude Code, put this in ~/.claude.json or a project .mcp.json:

{
  "mcpServers": {
    "pagedeltas": {
      "type": "http",
      "url": "https://api.pagedeltas.com/mcp",
      "headers": {
        "Authorization": "Bearer pdt_xxxxxxxx"
      }
    }
  }
}

For Cursor, use ~/.cursor/mcp.json. The shape is the same without the type field:

{
  "mcpServers": {
    "pagedeltas": {
      "url": "https://api.pagedeltas.com/mcp",
      "headers": {
        "Authorization": "Bearer pdt_xxxxxxxx"
      }
    }
  }
}

For VS Code Copilot, put a server entry in .vscode/mcp.json and read the key from an input prompt so it never lands in the repo:

{
  "servers": {
    "pagedeltas": {
      "url": "https://api.pagedeltas.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:pagedeltas-api-key}"
      }
    }
  }
}

Claude Desktop still prefers a local stdio process. Bridge with mcp-remote and an env var for the key:

{
  "mcpServers": {
    "pagedeltas": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://api.pagedeltas.com/mcp",
        "--header",
        "Authorization: Bearer ${PAGEDELTAS_API_KEY}"
      ]
    }
  }
}

Restart the client after you save. You should see tools such as create_monitor, list_monitors, list_monitor_changes, check_monitor_now, alert-channel helpers, sitemap monitor tools, and get_plan. There are also resources at pagedeltas://plan and pagedeltas://monitors, plus starter prompts named create_monitor and review_changes. Full tool names live in the MCP docs.

Prompts that create useful monitors

Once the tools show up, the test is whether natural language produces a quiet, useful watch. The brief goes in nl_description. Write it the way you'd brief a teammate: what the page is, what should wake you, and what to ignore.

Try a competitive pricing watch:

Use Page Deltas to create a monitor on https://competitor.example/pricing.
Name it "Competitor pricing". Brief: competitor pricing page. Alert when any
plan price changes, a plan is added or removed, or quotas and limits change.
Ignore cookie banners, A/B layouts, and rotating testimonials. Then list my
alert channels and attach Slack if one exists.

Or a regulator page you only need to hear about when something material moves:

Create a Page Deltas monitor on https://example-regulator.gov/dockets/acme.
Brief: public docket index. Alert when a new filing, comment deadline, or
hearing date appears. Ignore pagination chrome and "last updated" stamps that
do not change the filings list. After it is created, run check_monitor_now once.

Manual checks are limited to one per minute per monitor, which is enough after a deploy or after you edit a brief. For your own site after a release, the same pattern works: create the monitor with a "what should never happen" brief, then have the agent call check_monitor_now from a script or a chat when CI finishes.

When you come back days later, recover state from the durable side, not from chat memory:

List my Page Deltas monitors and show the three most recent changes on
"Competitor pricing". Summarize what moved and whether any change touched the
Enterprise tier.

That last prompt is where the stack pays off. The agent didn't keep a polling loop alive. It asked a persistent monitor for timestamped changes, then drafted the downstream note.

If you need push into your own system instead of asking the agent to poll, create a signed webhook channel (create_alert_channel) and attach it to the monitor. Delivery is a single attempt per channel today, with X-Signature: sha256= HMAC verification. Build the receiver to accept duplicates and respond quickly. Details are in the change-API post linked above.

How this compares with Visualping's MCP

Visualping published a guide to monitoring websites from Claude Code and Codex in May 2026. Both products now expose an MCP server so agents can create monitors and read changes. The differences are in the transport, the filter model, and what each Free plan asks you to ration.

Visualping's connector uses Server-Sent Events at https://visualping.io/mcp/sse. You often pick a fixed check interval in minutes. Their Free plan covers 5 pages and 150 checks per month, with a minimum interval of 60 minutes on Free (figures from Visualping's pricing page as of October 2026). Login-walled pages work on every Visualping plan through Actions or the Chrome extension. If the page you care about only exists after sign-in, Visualping is the better pick today. Page Deltas doesn't support login yet.

Page Deltas uses Streamable HTTP at https://api.pagedeltas.com/mcp. There's no interval field. Cadence is adaptive, active pages get checked more often, and every plan including Free has unlimited checks (best-effort frequency on Free, priority on paid). The primary filter is the natural-language brief (nl_description), not a region or importance flag you tune after the fact. Free covers 10 monitored URLs or sitemaps, 14-day history, AI filtering and summaries, all five alert channels (Slack, Discord, Teams, email, or a signed webhook), REST API, and MCP, with no credit card. Paid plans raise the URL cap and retention (Starter $29/mo for 150 URLs and 30-day history, Pro $79 for 1,000 and 90 days, and so on). The plan-for-plan product comparison is on Page Deltas vs Visualping.

Takeaway for agent setups: use Visualping when you need authenticated pages or a guaranteed short interval on a small set of URLs. Use Page Deltas when the pages are public, you want the brief to be the filter, and you don't want to budget monthly checks.

What the MCP will not do

A few flows stay on the dashboard or the REST API. CSV import, API-key management, team invites, and Stripe checkout aren't exposed over MCP. Agents shouldn't drive multipart uploads or billing UI.

We only see the public web. Marketing sites, public docs, careers boards, public PDFs, and sitemaps are in scope. Anything behind your login is out of reach until authenticated monitoring ships.

Between scheduled checks, a change waits for the next adaptive run unless you call check_monitor_now. If you need a fixed every-two-minutes hammer on one URL, a tool with a typed interval still owns that niche.

Destructive tools (deletes and bulk deletes) are marked as such in the client. Treat the API key like a password. Anyone holding it can create, pause, and delete monitors for the whole org.

Start with one URL from your agent

Pick a public page you already refresh by hand. Connect Claude Code, Cursor, or VS Code with the snippets above, create one monitor with a three-part brief, and ask the agent to list changes tomorrow. The Free plan covers 10 URLs or sitemaps with AI filtering, all five alert channels, REST API, and MCP, and it doesn't need a credit card. Start monitoring for free.

Julien, Product Manager at Page Deltas

How to monitor websites from Claude Code, Cursor, or VS Code with MCP · Page Deltas