Loading ToolBench
A Model Context Protocol (MCP) server for ChangeDetection.io that provides consolidated tools for managing watches, tags, notifications, history, system operations, and maintenance tasks
This MCP server defines 6 consolidated mega-tools that violate fundamental tool design principles. Each tool bundles 10-20+ distinct operations under a single name via an 'action' enum parameter. Tool names (watch_ops, tag_ops, notification_ops, history_ops, system_ops, maintenance_ops) do not start with verbs and mask the actual operations inside. Descriptions are generic boilerplate listing actions without explaining WHEN to use each operation or what the tool returns. Input schemas exist but are massive and confusing, many parameters are optional and conditional on the 'action' value, creating undocumented dependencies. Output schemas are not documented anywhere in the provided code. Error handling is absent from test cases and no recovery guidance is visible. While the server has basic structure and some tests, it violates the core principle that each tool should do exactly one thing (pattern:tool). This design forces LLMs to reason about which action to use rather than selecting a tool by name.
Consolidated tool for managing watch history and snapshots with actions: Retrieve list of all snapshot timestamps for a specific watch, Compare two snapshots and return the differences, Retrieve the full content of a specific snapshot, Capture or retrieve a visual screenshot of the current watch state, List all snapshots across all watches, Set a limit on the number of snapshots to retain, Retrieve technical metadata for a specific snapshot, Set a history retention limit for multiple watches
Consolidated tool for maintenance operations with actions: Initiate a backup of the ChangeDetection.io instance, Export all watches configuration to JSON format
Consolidated tool for managing global notification settings with actions: List all global notification endpoints, Add a new Apprise-compatible URL, Overwrite the entire list of global notification endpoints, Remove a specific Apprise-compatible URL
Consolidated tool for system operations with actions: Retrieve ChangeDetection.io server version and instance statistics
Consolidated tool for managing tags with actions: List all tags across all watches, Create a new tag, Retrieve detailed information for a specific tag, Update the title or properties of an existing tag, Permanently remove a tag
All 6 tools violate the single-responsibility principle by bundling 2-22 distinct operations under one tool name. Tool names (watch_ops, tag_ops, etc.) are noun phrases, not verb phrases, hiding the actual action inside an 'action' enum. This forces LLMs to reason about operation selection rather than tool selection, dramatically increasing error rates and token waste.
Descriptions are generic boilerplate ('Consolidated tool for managing watches with actions: List all...') that do not answer WHEN to use the tool, what it returns, or how to chain results downstream. Descriptions are 100+ chars but mostly list actions instead of explaining the tool.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | <=2025-11-25 | v2 |
Consolidated tool for managing watches with actions: List all current watches filtered by tag or state, Search for watches by URL or title, Retrieve detailed information for a specific watch, Add a new URL as a watch, Modify configuration of an existing watch, Permanently remove a watch, Manually trigger a check for changes, Pause monitoring, Resume monitoring, Mute/Unmute notifications, Import multiple URLs, Set selectors, Configure fetcher, Configure notifications, List watches in error state, List watches by processor, Set browser steps, Set conditions, Set request config, Get favicon, Trigger all watches, Mark as viewed
Input schemas embed undocumented conditional logic. Many parameters are optional but only valid for specific 'action' values. E.g. watch_ops 'uuid' is 'Required for most actions except List, Search, and Import', this dependency is buried in the description, not formalized. LLMs cannot validate inputs before calling.
Output schemas are completely undocumented. Tests show return fields (e.g. 'watches', 'tags', 'total', 'notifications') but schema definitions do not appear in the code. LLMs cannot plan chained calls or extract expected fields without guessing.
No error handling or recovery guidance anywhere in the codebase. Tests mock successful responses only. No error messages, status codes, or instructions for LLM retry logic are defined.
Destructive operations (Delete, Trigger, Backup, Export) have no confirmation, dry-run, or safety mechanisms. No indication in tool descriptions that these modify state. No audit trail or permission gates visible.
Parameter naming is inconsistent and overloaded. notification_ops uses both 'notification_url' (singular) and 'notification_urls' (array) depending on action. history_ops uses string parameters ('word_diff', 'changes_only') where booleans are clearer. This forces LLMs to track context-dependent param mapping.