Skip to main content
Glama
stack-and-dns-mcp
by Mewnah

Stop Watching Domain

unwatch_domain
DestructiveIdempotent

Stop monitoring a domain and delete its alerts by watchId or domain name. Use it to end tracking for a domain you no longer want monitored.

Instructions

Stop watching a domain (by watchId or domain); its alerts are deleted with it. Free.

Input Schema

NameRequiredDescriptionDefault
domainNoAlternative to watchId.
watchIdNo

Output Schema

NameRequiredDescriptionDefault
billingYes
removedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.8/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the actual consequence of the destructive flag: the domain's alerts are deleted along with the watch. It also adds cost information ("Free"), which is context the annotations cannot express. It does not say whether the operation errors on a non-existent watch or whether deletion is recoverable, so it falls short of a 5.

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?

One compact sentence with the action, the selectors, and the side effect front-loaded, plus a single-word cost note. Nothing is padded and nothing essential is buried.

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?

For a two-parameter tool with an output schema and annotations covering destructiveness and idempotency, the description supplies the key missing piece (alert deletion) plus cost. The remaining gap is the all-optional selector pair, where the description never explains the no-argument case.

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

Parameters3/5

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

Schema coverage is 50% and watchId has no description at all, so the description is the only place the either/or relationship between watchId and domain is reinforced. However it adds no detail on which selector takes precedence if both are given, or what occurs if both are omitted despite zero required parameters.

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?

States a specific verb+resource ("Stop watching a domain") that is the clear inverse of the sibling watch_domain, and names the two selectors it accepts. It stops short of explicitly naming watch_domain as the counterpart, so differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent infers you call this when you no longer want alerts for a domain. There is no explicit when-to-use/when-not, no guidance on preferring list_watches first to obtain a watchId, and no mention of what happens if neither selector is supplied.

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