stack-and-dns-mcp

Watch Domain for Changes

watch_domain

Idempotent

Schedule daily re-checks of a domain's email posture and technology stack, then get alerts when DMARC, SPF, DKIM, MX, score, or tools change. Optionally push signed webhook alerts.

Instructions

Re-check a domain every 24 hour(s) and raise an alert when its email posture (DMARC or SPF weakened, DKIM key lost, MX provider changed, score drop...) or technology stack (tool added or removed) changes. Alerts are read with get_alerts and can also be pushed to a signed webhook. Watching a domain again updates its checks and webhook. Plan keys include a number of watched domains; prepaid callers pay 1 credit(s) per scheduled check, and a watch pauses (with an alert) when the balance runs out and resumes after a top-up. Watching itself is free.

Input Schema

Name	Required	Description
`checks`	No	What to re-check on schedule.
`domain`	Yes	Domain to inspect. Accepts a bare hostname ("example.com"), a URL ("https://www.example.com/pricing") or an email address ("jane@example.com"). Scheme, path, port and query are stripped; IDN names are accepted.
`webhookUrl`	No	Optional https URL that receives each batch of alerts as a signed POST (header x-stackdns-signature: t=<unix>,v1=<hex HMAC-SHA256 of `${t}.${body}`>). Omit to use get_alerts only.

Output Schema

Name	Required	Description
`watch`	Yes
`billing`	Yes
`created`	Yes
`watchLimit`	Yes
`webhookSecret`	Yes	Signing secret for webhook deliveries, shown only when the watch is created. Store it now.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations by disclosing quota mechanics (plan keys include N watched domains), per-check cost (1 credit per scheduled check), the pause-on-zero-balance-and-resume-after-top-up behavior with an alert, and the free nature of the watch action itself. It also documents the webhook signature header format, which is operational detail no annotation supplies.

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 detection list, then billing and delivery details in descending priority. The parenthetical trigger list and "1 credit(s)"/"24 hour(s)" phrasing add minor clutter, but nearly every sentence carries operational information an agent needs.

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?

For a recurring-schedule mutation tool with an output schema already defined, the description covers what changes, how alerts are delivered, idempotency of repeat calls, and cost/pause semantics. Nothing material about calling it correctly is left unexplained.

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 100%, so parameters are already well documented. The description still adds meaning by tying the checks enum to concrete alert triggers (email posture vs. technology stack) and clarifying that omitting webhookUrl means pull-only via get_alerts, and that re-watching overwrites existing checks and webhook.

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?

States a specific verb and resource ("Re-check a domain every 24 hour(s) and raise an alert") plus the exact change conditions it detects (DMARC/SPF weakening, DKIM loss, MX provider change, score drop, tech added/removed). This is clearly separable from siblings like unwatch_domain, domain_history, and get_alerts.

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?

Explains the consumption path ("Alerts are read with get_alerts and can also be pushed to a signed webhook") and the idempotent-update semantics ("Watching a domain again updates its checks and webhook"). It does not explicitly contrast with one-off siblings such as comprehensive_audit or verify_email_infrastructure, so the agent must infer when a one-time check is preferable to a recurring watch.

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

Deploy Server