Skip to main content
Glama
si-essence

changedetection-mcp

by si-essence

changedetection_create_watch

Creates a watch to monitor a URL for changes, with an optional dry-run preview before confirming the write.

Instructions

Create a watch. POST /api/v1/watch. Requires url. Supports processor restock_diff, price fields, and llm_intent / llm_change_summary. Omit confirm for a dry-run.

Input Schema

NameRequiredDescriptionDefault
tagNoDeprecated. Comma-separated tag names, matched case-insensitively and created when missing.
urlYesURL to monitor.
bodyNo
tagsNoTag UUIDs. Unknown UUIDs are stored but resolve to no group.
proxyNo
titleNoWatch title, not the HTML page title.
methodNo
pausedNo
confirmNoSet to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
headersNoHTTP headers for the fetch. Authorization and cookie values are redacted in output.
processorNotext_json_diff is the default. restock_diff tracks stock and price.
conditionsNo
llm_intentNoPlain-English intent for AI change filtering.
ignore_textNo
extract_textNo
link_to_openNoHuman-facing URL to open instead of url. Empty string means use url.
trigger_textNo
browser_stepsNo
fetch_backendNoFetcher. Common values: system, html_requests, html_webdriver.
in_stock_onlyNorestock_diff: only notify on in-stock transitions.
include_filtersNo
webdriver_delayNo
filter_text_addedNo
notification_bodyNo
notification_urlsNoApprise notification URLs for this watch. Tokens in URLs are redacted in output.
check_unique_linesNo
llm_change_summaryNoInstructions for the AI to summarise changes in notifications.
notification_mutedNo
notification_titleNo
time_between_checkNo
filter_text_removedNo
ignore_status_codesNo
llm_backend_profileNoWatch: boolean on/off. Tag: true/false/null ternary AI control.
notification_formatNo
strip_ignored_linesNo
time_schedule_limitNo
filter_text_replacedNo
follow_price_changesNorestock_diff: track price changes.
trim_text_whitespaceNo
subtractive_selectorsNo
conditions_match_logicNo
remove_duplicate_linesNo
use_page_title_in_listNo
llm_change_summary_modeNo
notification_screenshotNo
track_ldjson_price_dataNo
extract_lines_containingNo
sort_text_alphabeticallyNo
webdriver_js_execute_codeNo
text_should_not_be_presentNo
history_snapshot_max_lengthNo
price_change_threshold_percentNo
time_between_check_use_defaultNo
filter_failure_notification_sendNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

The description goes beyond static input parameters to explain the tool's core behavioral capabilities, specifically listing supported processors ('restock_diff') and advanced AI fields ('llm_intent / llm_change_summary'). This provides crucial functional context missing from the raw schema.

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 definition is incredibly efficient, using two sentences to convey the core function, the API endpoint, major feature sets, and a critical operational workflow (dry-run). There is zero unnecessary fluff.

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?

While the tool has over 50 parameters, the description efficiently directs the agent to the most complex behavioral areas. It adequately covers the 'how' (dry-run mechanism) and 'what' (advanced processor support) needed to use the tool, even if exhaustive parameter details are relegated to the schema.

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?

Given the extremely low schema description coverage (28%), the description is highly valuable. It explicitly references several complex or niche parameters like 'restock_diff' and the LLM fields, allowing the agent to understand the tool's feature set despite poor schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's action ('Create a watch') and the execution path ('POST /api/v1/watch'). It differentiates the tool's purpose from other functions by listing key specialized features like processor support and LLM integration.

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 provides an essential workflow constraint: omitting the 'confirm' field facilitates a dry-run. This guidance is critical for agents performing safe initial setup before committing resources.

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