Skip to main content
Glama
webscout-mcp

webscout-mcp

by wxs-lang

web_monitor

Check a URL for changes since the last snapshot, reporting text updates, price moves, and keyword appearances so you can track pages across calls.

Instructions

Check a URL for changes since the last check, and return what changed.

Compares the page against the last snapshot stored on disk and reports text changes, price moves, and keyword appearances or disappearances. Useful for tracking a page across sessions: docs, prices, availability, job postings.

This checks once per call. It does not schedule itself - an MCP tool is passive. To monitor continuously, call it again from your MCP client or an external scheduler. The first call for a URL only records a baseline and returns no changes.

Use ignore_text (regexes) for values that change on every request such as timestamps or session ids, and ignore_selector (CSS) for regions that churn independently such as ad slots. Without them most pages report a change every time, which is why they exist.

Price watching is independent of min_change_size: a one-character move like $100.00 to $900.00 is exactly what a text threshold would swallow, so it is compared as a percentage when price_selector is set.

json_path watches one value inside a JSON response instead of the whole body: json:$.product.price uses JSONPath, jq:.product.price uses jq (needs the [json] extra; JSONPath needs it too). Reducing an API response to one field is what makes it stable enough to monitor - markup and prose churn, a price field does not. Without json_path the whole body is compared as before.

notify takes target URLs such as webhook://example.com/hook, dingtalk://oapi.dingtalk.com/robot/send?access_token=X, telegram://TOKEN@CHAT or smtp://user:pass@host:587?to=a@b.c. When a change is found it is pushed to those channels, and the send result is reported in notifications. Credentials stay in the URL and are never echoed back.

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": {
      "url": "<url>"
    },
    "name": "web_monitor"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
notifyNo
json_pathNo
state_pathNo
ignore_textNo
include_diffNo
price_selectorNo
ignore_selectorNo
keywords_appearNo
min_change_sizeNo
price_change_thresholdNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With zero annotations, the description carries the full burden and does so: it discloses on-disk snapshot state, the no-changes baseline on first call, the passive one-call-per-invocation model, the false-positive risk without ignore_* filters, the price-vs-text comparison independence, and that notification send results appear in `notifications` with credentials never echoed. Essentially every non-obvious behavior an agent needs is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and structured into topical paragraphs keyed to the harder parameters. It is long with some conversational filler ('what a price... a filter threshold would...', 'which is why they exist'), but most sentences carry real operational guidance for an 11-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A complex, stateful, 11-parameter tool with no annotations and an output schema (so return shapes need not be described). The description covers the operational model, filter necessity, JSON reduction, and notification side effects — enough for an agent to invoke it correctly on the first try.

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 coverage is 0% across 11 params, so the description must compensate, and it does for most: notify URL schemes,_path JSONPath/jq syntax and the `[json]` extra, ignore_text as regex, ignore_selector as CSS, price_selector and min_change_size behavior. Gaps remain for state_path, include_diff, and price_change_threshold, which get no explanation anywhere.

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?

Opens with a specific verb+resource+scope: 'Check a URL for changes since the last check, and return what changed.' The stateful snapshot comparison implicitly and clearly separates it from stateless siblings like web_fetch or web_extract, and it enumerates the change types (text, price, keyword) it reports.

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?

Strong context on when to use it ('tracking a page across sessions: docs, prices, availability, job postings') plus important exclusions ('does not schedule itself', first call is baseline-only). It never names or routes against specific siblings such as web_compare_sites, so it falls short of the 5 bar for explicit alternatives.

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