How do I use mcp-page-monitor?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-page-monitor Monitor https://example.com for changes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-page-monitor

by deialedin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

mcp-page-monitor

MCP server for monitoring web page changes. Uses Playwright to capture page content, SQLite for snapshot storage, and optional LLM integration for business impact analysis.

Available on npm and the MCPize marketplace.

Tools

`monitor_page`

Parameter	Type	Required	Description
`url`	string	yes	URL to monitor
`label`	string	no	Human-readable label
`selector`	string	no	CSS selector to monitor a specific element
`check_interval_minutes`	number	no	Check frequency (1–10080). Default: 60

`check_changes`

Browse a monitored URL with Playwright, capture current content, and diff against the stored snapshot.

Parameter	Type	Required	Description
`url`	string	yes	URL to check (must be registered first)

Returns { changed, diff, timestamp } — diff includes added/removed line counts, changed sections, and a unified diff string.

`analyze_change`

Analyze a page diff using an LLM to summarize what changed and assess business impact.

Parameter	Type	Required	Description
`url`	string	yes	URL whose changes to analyze
`diff_text`	string	no	Provide diff text directly instead of computing from snapshots

Returns { summary, impact, severity } — severity is low | medium | high | critical.

Falls back to deterministic analysis (pattern matching for pricing changes, errors, policy updates, etc.) when no LLM endpoint is configured.

`list_monitored_pages`

List all URLs currently being monitored.

`remove_monitored_page`

Stop monitoring a URL.

Parameter	Type	Required	Description
`url`	string	yes	URL to stop monitoring

Related MCP server: diffgrab

Installation

npm install mcp-page-monitor

Or run directly:

npx mcp-page-monitor

Requirements

Node.js 22+
Chromium browser (Playwright uses it for page rendering)

Install Playwright browsers if needed:

npx playwright install chromium

Configuration

Claude Desktop / Cursor / MCP Client

Add to your MCP client config:

{
  "mcpServers": {
    "page-monitor": {
      "command": "npx",
      "args": ["mcp-page-monitor"],
      "env": {
        "PLAYWRIGHT_CHROMIUM_PATH": "/usr/bin/chromium-browser"
      }
    }
  }
}

Environment Variables

Variable	Default	Description
`PAGE_MONITOR_DB_PATH`	`~/.mcp-page-monitor/page-monitor.db`	SQLite database location
`PLAYWRIGHT_CHROMIUM_PATH`	`/usr/bin/chromium-browser`	Path to Chromium executable
`CHROME_PATH`	—	Fallback browser path
`PAGE_TIMEOUT_MS`	`30000`	Page navigation timeout
`LLM_ENDPOINT`	—	LLM API endpoint for `analyze_change` (e.g. OpenAI-compatible `/v1/chat/completions`)
`LLM_API_KEY`	—	Bearer token for LLM endpoint
`LLM_MODEL_ID`	`gpt-4o-mini`	Model to use for analysis
`LLM_SOURCE_SYSTEM`	`mcp-page-monitor`	Source identifier sent to LLM

How It Works

Register a page with monitor_page — takes an initial snapshot via headless Chromium
Check for changes with check_changes — fetches current content and computes a line-level diff (LCS-based) against the last snapshot
Analyze changes with analyze_change — sends the diff to an LLM for business impact assessment, or uses built-in heuristics (pricing detection, error detection, policy changes) when no LLM is available

All snapshots are stored in a local SQLite database with WAL mode enabled for concurrent access.

Development

git clone https://github.com/deialedin/mcp-page-monitor
cd mcp-page-monitor
npm install
npm run build       # Compile TypeScript
npm test            # Run 26 tests
npm run dev         # Watch mode with tsx

License

MIT

Available Tools

5 tools

analyze_changeA

Send a page diff to an LLM and get a business impact analysis including severity, change type, key changes, and recommended actions.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL whose changes to analyze
`diff_text`	No	Optional: provide diff text directly instead of computing from latest snapshots

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool sends data to an LLM and returns specific fields, which is useful behavioral context. However, it doesn't state whether the operation is read-only, its side effects, or any rate/authorization requirements.

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?

The description is one sentence, clear, and front-loaded with the action and outcome. Every word earns its place without repetition or unnecessary detail.

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?

The tool has no output schema or annotations, but the description compensates by enumerating the expected analysis fields. The input schema is fully described, and the description clarifies the purpose. Missing elements like explicit side-effect disclosure are minor given the tool's analytical nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the two parameters (url, diff_text). The description adds no new parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly identifies the action ('send to an LLM') and the resource ('page diff') with a specific output ('business impact analysis'). It distinguishes itself from sibling tools like check_changes by emphasizing LLM-based impact analysis rather than simple diff detection.

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?

The description implies clear usage context: use when you need business impact analysis of a page diff. It doesn't explicitly state when not to use or name alternatives, but the distinct function (analysis vs. monitoring/checking) provides sufficient guidance.

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

check_changesA

Browse a monitored URL with Playwright, capture current content, diff against the stored snapshot, and return any changes found.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to check for changes (must be previously registered)

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description takes on the burden of explaining behavior. It discloses the use of Playwright for browsing, the process of capturing and diffing content, and that it returns changes. This goes beyond a simple 'check changes' and gives insight into side effects like network access and comparison logic. However, it does not reveal exact return format or behavior when no changes exist.

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?

The description is a single sentence that is action-packed and front-loaded. Every phrase adds value, and it avoids filler.

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?

The tool is simple with one fully documented parameter. The description covers the core workflow and output intention. It lacks detail on return structure and error cases, but for a tool this simple with a full schema, it is sufficient. Not as complete as the model example, but a solid 4.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the url parameter (100% coverage), so the baseline is 3. The description adds the qualifier 'monitored URL' which aligns with the parameter's mention of 'previously registered', but it does not add new semantic detail beyond the schema.

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 clearly states the tool's function: browsing a monitored URL and returning changes. It uses specific verbs (browse, capture, diff, return) and names the resource (monitored URL). It distinguishes from siblings like monitor_page and analyze_change by focusing on the checking action.

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 the tool is for already-monitored URLs (browsing a 'monitored URL'), and the parameter description adds the prerequisite 'must be previously registered'. However, it does not explicitly contrast with sibling tools or state when to prefer this over analyze_change. Guidance is implicit rather than explicit.

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

list_monitored_pagesA

List all URLs currently being monitored for changes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. 'List all URLs' clearly indicates a read-only, non-destructive operation. It does not disclose details like ordering or pagination, but for a simple listing tool, the behavioral profile is transparent enough.

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?

The description is a single, well-structured sentence that is immediately informative. It front-loads the action and contains no fluff or redundancy.

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?

Given the tool's simplicity (0 parameters, no output schema), the description sufficiently conveys what it does and implies the return value is a list of URLs. It doesn't elaborate on formatting or edge cases, but these are not critical for a basic list operation.

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 tool has zero parameters, so schema coverage is 100% by default. The description adds no parameter details because there are none to explain. This aligns with the baseline for 0-parameter tools.

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 clearly states the tool's purpose with a specific verb ('List') and resource ('URLs currently being monitored for changes'). It unambiguously distinguishes from sibling tools like monitor_page (adds monitoring) and remove_monitored_page (deletes monitoring).

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 when to use the tool (to view monitored URLs) but does not explicitly mention alternatives or when-not-to-use. Sibling tools exist, so explicit differentiation would enhance guidance, but the purpose itself is self-evident.

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

monitor_pageA

Register a URL to watch for changes. Takes an initial snapshot immediately. Optionally specify a CSS selector to monitor a specific element.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to monitor for changes
`label`	No	Human-readable label for this page
`selector`	No	CSS selector to monitor a specific element instead of the full page
`check_interval_minutes`	No	How often to check for changes (1 min to 7 days). Default: 60

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the immediate snapshot behavior, which is useful. However, it doesn't mention persistence, what happens on duplicate registrations, authorization requirements, or the return value. More behavioral disclosure would be expected for a write operation without annotations.

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?

The description is two sentences, front-loaded with the core action, and every word earns its place. No redundancy or 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 is simple with well-covered parameters, but there is no output schema and no mention of what the tool returns (likely an identifier used with siblings like check_changes). The workflow context is implied but not explicit. For a registration tool in a multi-step process, more guidance on integration would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description's mention of 'optionally specify a CSS selector' adds no new information beyond what the schema states. It doesn't clarify formats, defaults, or parameter interactions, so baseline 3 is appropriate.

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 clearly states the action ('Register a URL to watch for changes') and the resource (URL/page). It differentiates from siblings by focusing on registration/setup, whereas check_changes, analyze_change, list_monitored_pages, and remove_monitored_page handle other lifecycle stages.

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?

The context is clear: this tool registers a URL for change monitoring. It doesn't explicitly mention alternatives or when-not-to-use, but the description makes it the obvious starting point relative to siblings. There are no exclusions mentioned, which is fine for a registration tool.

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

remove_monitored_pageA

Stop monitoring a URL and deactivate it from the watchlist.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to stop monitoring

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the key behavioral effect (deactivating the page from the watchlist), but does not elaborate on reversibility, permission requirements, or side effects. The description is decent but not rich enough for a mutation tool.

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?

The description is a single, efficient sentence that front-loads the primary action. No filler words or redundant information—every word adds value.

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 simple tool with one parameter and no output schema, the description plus schema adequately explain the operation. It could mention that the URL must already be monitored, but this is reasonably inferred from the name and siblings. The description is complete enough for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the only parameter 'url' with a clear description and 100% coverage. The tool description adds no extra semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states the action: 'Stop monitoring a URL and deactivate it from the watchlist.' It specifies both the verb (stop monitoring / deactivate) and the resource (URL/monitored page), and it distinguishes itself from siblings like monitor_page, check_changes, and analyze_change.

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?

There is no explicit guidance on when to use this tool versus alternatives, but the purpose implies usage when you want to stop monitoring a URL. It does not mention exclusions or refer to sibling tools, so the guidance is only implied.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Aug 9, 2026
- First observedanalyze_change
- First observedcheck_changes
- First observedlist_monitored_pages
- First observedmonitor_page
- First observedremove_monitored_page

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-09 21:35 across 5 tools

Disambiguation5/5

Each tool has a distinct role in the monitoring lifecycle: registering, checking, analyzing, listing, and removing. There is no overlap or ambiguity between their purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (monitor_page, check_changes, analyze_change, list_monitored_pages, remove_monitored_page). The naming is uniform and predictable.

Tool Count5/5

With exactly 5 tools, the set is well-scoped for a page monitoring service. Each tool covers a necessary operation without unnecessary bloat.

Completeness4/5

The core lifecycle of adding, checking, listing, and removing monitored pages is fully covered, plus an analysis step. A minor gap is the lack of an update operation (e.g., changing the CSS selector), requiring remove and re-add, but this is not a significant workflow blocker.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Austin Oaks Page Watch A
com.freshypenguin
Watch a public web page for changes when your agent cannot stay running. Hourly checks, signed diffs
Browser Automation Web Scraping
31
mcp A
io.competitortracker
Track competitors from your AI assistant: change feed, page snapshots, labels and alerts.
Web Scraping Monitoring
12
Hypeline
io.hypeline
Give an AI agent eyes on the web: turn any feed, page, or stream into deduplicated change events.
Browser Automation Web Scraping
2
Snapshot SiteOAuth
com.snapshot-site
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
Testing & QA Tools Image & Video Processing AI & Machine Learning
41

Related MCP Servers

WebWatch MCP
Browser Automation Web Scraping
Leviai-ai
A
license
Not graded
quality
D
maintenance
An MCP server for monitoring website changes. Enables tracking URLs, detecting content changes, comparing snapshots, and extracting content with CSS selectors from an AI assistant.
Updated 5 months ago (2026-04-02 21:57 UTC)
8 npm
MIT
diffgrab
Browser Automation Web Scraping
QuartzUnit
A
license
Not graded
quality
D
maintenance
Enables tracking web page changes, detecting content modifications with structured diffs and snapshot history through MCP tools.
Updated 5 months ago (2026-04-15 01:59 UTC)
26 PyPI
MIT
siteglass-mcpofficial
Browser Automation Web Scraping Testing & QA Tools
siteglassio
A
license
Not graded
quality
B
maintenance
Enables archival of any public URL as interactive snapshot (rrweb, PDF, PNG) and autonomous web QA for apps (register, scan, generate and run end-to-end flows).
Updated 2 months ago (2026-07-19 22:07 UTC)
31 npm
MIT
mcp-page-monitor
Browser Automation Web Scraping
wzx11223344
F
license
Not graded
quality
C
maintenance
Enables AI assistants to monitor web pages for content changes and receive alerts when changes occur.
Updated 2 months ago (2026-07-18 14:41 UTC)
-

mcp-page-monitor

Tools

monitor_page

check_changes

analyze_change

list_monitored_pages

remove_monitored_page

Installation

Requirements

Configuration

Claude Desktop / Cursor / MCP Client

Environment Variables

How It Works

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

siteglass-mcpofficial

`monitor_page`

`check_changes`

`analyze_change`

`list_monitored_pages`

`remove_monitored_page`