mcp-page-monitor
# 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](https://www.npmjs.com/package/mcp-page-monitor) and the [MCPize marketplace](https://mcpize.com).
## Tools
### `monitor_page`
Register a URL to watch for changes. Takes an initial snapshot immediately.
| 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 |
## Installation
```bash
npm install mcp-page-monitor
```
Or run directly:
```bash
npx mcp-page-monitor
```
### Requirements
- Node.js 22+
- Chromium browser (Playwright uses it for page rendering)
Install Playwright browsers if needed:
```bash
npx playwright install chromium
```
## Configuration
### Claude Desktop / Cursor / MCP Client
Add to your MCP client config:
```json
{
"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
1. **Register** a page with `monitor_page` — takes an initial snapshot via headless Chromium
2. **Check** for changes with `check_changes` — fetches current content and computes a line-level diff (LCS-based) against the last snapshot
3. **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
```bash
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
TDQS
Scored across 5 tools
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.
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.
With exactly 5 tools, the set is well-scoped for a page monitoring service. Each tool covers a necessary operation without unnecessary bloat.
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.