Skip to main content
Glama
KnockOutEZ

wigolo

by KnockOutEZ
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

watch

Monitor URLs for changes and get diffs. Schedule lazy checks that trigger on next tool call or manually. Persist jobs across server restarts.

Instructions

Schedule lazy re-checks of a URL and surface diffs on change. Persistent across sessions — jobs survive MCP server restarts.

LAZY EXECUTION — NOT CRON. There is no background daemon. Checks fire ONLY when:

  1. You explicitly call watch({ action: 'check', job_id }), OR

  2. Any OTHER wigolo tool runs and the job's interval has elapsed (overdue jobs are triggered fire-and-forget in the background). A job on an idle MCP server will not fire until the next tool call. Do not expect cron-like accuracy.

Key parameters:

  • action: 'create' | 'list' | 'check' | 'pause' | 'resume' | 'delete'.

  • url (create-only): must be a public http/https URL. Loopback, RFC 1918 ranges, link-local, and non-http(s) schemes are rejected at registration.

  • interval_seconds (create-only): minimum 60 — sub-minute polling is refused to respect target-site rate limits.

  • selector (create-only, optional): CSS selector for future selector-scoped diffs. Persisted now for forward compatibility; the diff is currently full-page.

  • notification (create-only, optional): 'inline' (default — change reports come back on the next action: 'check') or a public webhook URL. Same SSRF guard as url. Webhook delivery is best-effort POST — no retry / no queue / no backoff.

  • job_id (check/pause/resume/delete).

list returns each job's staleness_seconds so you can see how overdue each check is: negative = not yet due, positive = overdue by N seconds. Pair with action: 'check' to force one immediately.

Idempotent create: identical url + interval + selector returns the existing job_id — does not duplicate the row.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoSingle-URL create: the URL to watch. Response carries `job` (singular) and `jobs:[job]` (legacy). Mutually exclusive with `urls`.
urlsNoBatch create: register multiple jobs in one call. Response carries `jobs[]` only (no `job`). Mutually exclusive with `url`.
actionYesWatch-job action.
job_idNoRequired for action=check|pause|resume|delete.
selectorNoOptional CSS selector to scope the diff to a subtree (create-only).
notificationNo"inline" (return on next check) or a webhook URL. Default: inline.
interval_secondsNoRequired for action=create. Minimum check interval (min 60).

Tool Definition Quality

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: lazy execution, session persistence, SSRF guards, minimum interval, best-effort webhook, idempotent create, and response details like staleness_seconds. No contradictions.

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?

The description is well-structured with clear sections and is appropriately sized for the complexity. However, it is slightly verbose in places; a more compact version could improve readability without losing information.

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?

Despite no output schema, the description covers all necessary context: actions, parameters, lazy execution, response fields, and edge cases like idempotency. It is highly complete for guiding correct tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds substantial meaning beyond the schema: mutual exclusivity of url/urls, selector future compatibility, notification options with webhook behavior, and required job_id per action. It enriches the parameter understanding.

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 clearly states the tool's purpose: 'Schedule lazy re-checks of a URL and surface diffs on change'. It distinguishes from sibling tools like 'crawl', 'fetch', and 'diff' by emphasizing its persistent scheduling and lazy check mechanism.

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?

The description explains when to use it versus alternatives, detailing the lazy execution model and conditions for checks. It provides explicit guidance for immediate use via action: 'check', but could be more explicit about when not to use it (e.g., for real-time updates).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KnockOutEZ/wigolo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server