Site Audit MCP Server

Page change monitor

monitor_page_changes

Compare public pages to saved snapshots and report added, removed, or changed content with plain-words summaries; filter routine timestamps and ads. The first call stores the baseline.

Instructions

Check public pages against their previous snapshot and report new/unchanged/changed with a plain-words summary of what changed (price, date and number changes, added/removed sections) and routine noise (timestamps, ads) filtered out. The first call for a watchlist stores the baseline; later calls report changes. Use the same watchlistId each time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pages": "<pages>"
    },
    "name": "monitor_page_changes"
  }
}

Input Schema

Name	Required	Description
`pages`	Yes	Pages to watch; optional CSS selector limits the watched region.
`dryRun`	No	Not supported by this Actor; ignored.
`maxCostUsd`	No	Optional hard cap in USD for this call. The underlying Actor stops when the cap is reached. Minimum 0.05 (the Apify per-run minimum). Default: a small amount computed from the number of URLs, never below 0.05.
`watchlistId`	No	Name of the watchlist (default "mcp"). Keep it the same between calls.
`skipNoiseOnlyChanges`	No	Report noise-only changes (timestamps, ads) as unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and idempotentHint=false, which could puzzle an agent for a tool framed as a 'check'; the description resolves this by disclosing that the first call persists a baseline. It also adds substantive behavior beyond annotations — noise filtering of timestamps and ads, and the nature of the summary returned. It does not mention that each call consumes a paid Actor run, leaving cost disclosure entirely to the maxCostUsd schema field.

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?

Three sentences, front-loaded with the core action and output shape, then the stateful baseline rule, then the parameter constraint. No redundant restatement of the title or name.

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?

There is no output schema, so the description correctly carries the return-value burden by describing the new/unchanged/changed verdicts and the plain-words summary. For a stateful, open-world, cost-bearing tool it could still say what happens on unreachable pages or failed baselines, which is the only meaningful gap.

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 baseline is 3; the description earns an increment by explaining the cross-call persistence contract of watchlistId ('use the same watchlistId each time') and by framing the pages list as a watchlist with a snapshot baseline. It doesn't clarify the dryRun-ignored quirk or selector precedence, but those are already documented in 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 names a specific verb and resource — checking public pages against a stored snapshot — and enumerates the output states (new/unchanged/changed) plus the plain-words change summary. That is enough to separate it from the audit_* and detect_tech_stack siblings, which inspect a page once rather than diff it against a prior snapshot.

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?

It gives clear operational context: the first call establishes the baseline, subsequent calls report changes, and the same watchlistId must be reused. What's missing is any explicit exclusion or routing statement (e.g., when to prefer a one-shot audit tool instead), so it stops short of full when/when-not guidance.

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

Deploy Server