DomainKits

Personalized Domain Monitor

monitor

Destructive

Manage cross-platform domain monitoring tasks that track changes in WHOIS, DNS, and host-supplied page content. Data is encrypted at rest (AES-256-GCM) in a private per-user directory.

Actions:

get: retrieve monitors and check eligible WHOIS/DNS targets, returning current and previous data with change flags.
set: create a monitor, subject to the account tier's maximum.
update: save host-supplied page, WHOIS, or DNS state for a monitor.
delete: remove a monitor.
history: list the changes actually observed over time, optionally for one domain. get compares against the previous check only; history answers when a domain changed and what it changed from.

Requires a registered account with memory enabled.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Monitor task ID (update and delete)
`dns`	No	DNS result, backward compatibility (update only)
`days`	No	history only: how far back to look, in days. Default 30, maximum 365.
`note`	No	What to watch for: the user's intent in natural language (set only)
`page`	No	Page content summary from web_fetch (update only)
`tools`	No	Comma-separated: whois, dns, web_fetch. Default: whois,dns (set only)
`whois`	No	WHOIS result, backward compatibility (update only)
`action`	No	'get', 'set', 'update', 'delete', or 'history'. Defaults to 'get' if not specified.
`domain`	No	Domain to monitor (set; also optional on history to filter to one domain)

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Error message when success is false
`total`	No	Number of active monitors (get only)
`message`	No	Human-readable result message
`monitor`	No	Created monitor details (set only)
`success`	Yes	Whether the request was successful
`monitors`	No	List of monitors with auto-check results (get only)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / note / description

Previous value: -"What to watch for — user's intent in natural language (set only)"New value: +"What to watch for: the user's intent in natural language (set only)"

Changed3 schema fields changedAug 22, 2026

changedInput schema / properties / action / description

Previous value: -"'get', 'set', 'update', or 'delete'. Defaults to 'get' if not specified."New value: +"'get', 'set', 'update', 'delete', or 'history'. Defaults to 'get' if not specified."

addedInput schema / properties / days

Added value: +{
+  "description": "history only: how far back to look, in days. Default 30, maximum 365.",
+  "type": "string"
+}

changedInput schema / properties / domain / description

Previous value: -"Domain to monitor (set only)"New value: +"Domain to monitor (set; also optional on history to filter to one domain)"

AddedJul 27, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds non-obvious context beyond that: AES-256-GCM encryption in a per-user directory, the requirement of a registered account with memory enabled, and that set is capped by the account tier's maximum. It lacks detail on pagination or failure behavior, but the additions are substantive.

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-loads the purpose sentence, then a scannable action list, then prerequisites. Every line earns its place, though the action list is slightly verbose relative to the information density needed.

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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies prerequisites, encryption, tier limits, and action meanings, leaving little an agent needs for correct invocation, though sibling routing remains unaddressed.

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 the baseline is 3, but the description goes further by explaining what the action values actually do (get/set/update/delete/history) and clarifies the get-vs-history relationship, which the bare enum list in the schema does not convey.

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 and resource ('Manage cross-platform domain monitoring tasks that track changes in WHOIS, DNS, and host-supplied page content'), which clearly conveys what the tool does. It does not, however, differentiate itself from plausible siblings like domain_changes or whois/dns, so an agent must infer which of the overlapping tools to use.

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?

Provides explicit per-action semantics and a genuinely useful distinction between get (compares against the previous check only) and history (when a domain changed and what it changed from). It stops short of naming sibling alternatives or when NOT to use this multi-action tool over e.g. domain_changes.

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

All DomainKits tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.