Anakin

Official

Overview Schema Source Related Servers Discussions Admin

monitor_create

Destructive

Create a scheduled website monitor that checks a URL at set intervals, detects meaningful content changes, and sends email or webhook alerts.

Instructions

Create a scheduled website monitor that checks a URL every intervalMinutes (min 15) and records a change when the content differs — optionally alerting a webhook or email. scope "page" (default) watches one URL; "site" crawls the site each run and tracks pages added/removed/changed; "wire" runs a Wire action each check and diffs its JSON. watchMode "full_page" (2 credits/check) compares the whole page; "specific_data" (3 credits/check) extracts only the fields in outputSchema with AI — ideal for price/stock/status tracking. aiMode (+1 credit/check) filters out trivial noise and summarizes real changes. Active-monitor caps per plan: Free 5, Pro 20, Scale 100.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to watch (root URL for site scope; the Wire site's URL for wire scope).
`scope`	No	What to monitor: one page (default), a whole site, or a Wire action.	page
`aiGoal`	No	Natural-language description of which changes count as meaningful (used with aiMode), e.g. "only when the price drops or it goes out of stock".
`aiMode`	No	AI meaningful-change filtering: ignores trivial noise (ads, timestamps) and summarizes real changes. +1 credit per check.
`country`	No	Two-letter proxy country code. Defaults to "us".	us
`isActive`	No	Start running immediately. Defaults to true.
`maxDepth`	No	Site scope: crawl depth (1–5). Defaults to 2.
`maxPages`	No	Site scope: max pages crawled per run.
`expiresAt`	No	Optional end date (ISO 8601 timestamp or YYYY-MM-DD); the monitor auto-pauses when it passes.
`sessionId`	No	Saved browser-session ID for monitoring login-protected pages (see session_list).
`watchMode`	No	Compare the whole page (default) or only the fields in outputSchema, extracted with AI.	full_page
`useBrowser`	No	Render checks with a stealth headless browser (needed for JS-heavy pages). Forced true when sessionId is set.
`wireParams`	No	Wire scope: parameters passed to the action each check.
`alertEmails`	No	Comma-separated email recipients for change alerts.
`watchFormat`	No	Format compared in full_page mode. Defaults to markdown.	markdown
`outputSchema`	No	JSON Schema of the fields to track. Required when watchMode is "specific_data".
`wireActionId`	No	Wire scope (required there): the Wire action run each check, e.g. "amazon.search_products" (see wire_discover).
`wireWatchPaths`	No	Wire scope: JSON paths to diff instead of the whole response.
`alertWebhookUrl`	No	Webhook URL that receives signed change alerts.
`excludePatterns`	No	Site scope: glob patterns to skip.
`includePatterns`	No	Site scope: glob patterns or hand-picked same-site URLs to track.
`intervalMinutes`	Yes	Check frequency in minutes. Minimum 15.
`wireCatalogSlug`	No	Wire scope: catalogue slug of the Wire site.
`wireCredentialId`	No	Wire scope: credential ID when the action needs auth (see wire_identities).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`url`	No
`scope`	No
`isActive`	No
`watchMode`	No
`watchFormat`	No
`intervalMinutes`	No
`alertWebhookSecret`	No	Always redacted before being returned — retrieve the real value from the Anakin dashboard.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint, openWorldHint), the description discloses per-check credit costs, active-monitor plan caps (Free 5, Pro 20, Scale 100), auto-pause on expiresAt, and the forced useBrowser=true when sessionId is set. This is substantial behavioral context that annotations alone do not provide.

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 description is long, but for a 24-parameter tool with three scopes and two watch modes, it is tightly packed and front-loaded with the core behavior. Every sentence contributes either a definition, a constraint, a cost, or a cross-reference; there is no filler.

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?

Given the tool's complexity, the description covers the essential behavior, scopes, modes, costs, plan limits, required-parameter relationships, and related tools. An output schema exists, so return-value documentation is unnecessary, and the description fully equips an agent to configure a correct monitor creation call.

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?

Even with 100% schema description coverage, the description adds cross-parameter constraints and semantics: outputSchema is required when watchMode='specific_data', wireActionId is required in wire scope, useBrowser is forced true with sessionId, and credit costs differentiate watchMode/aiMode. These relationships are not present 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 opens with a specific verb+resource: 'Create a scheduled website monitor that checks a URL every intervalMinutes...'. It clearly differentiates this from one-off fetching tools like scrape or crawl by emphasizing scheduled/recurring behavior, and the scope/watchMode variants are all explained.

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 strong contextual guidance: scope options, watchMode selection criteria ('ideal for price/stock/status tracking'), and when a browser is needed ('JS-heavy pages'). It references related tools (session_list, wire_discover, wire_identities), though it stops short of explicitly saying when NOT to use monitor_create in favor of a sibling like scrape.

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