Domotz Alerts — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Domotz Alerts (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Domotz alert profiles define what conditions the platform watches and where it sends notifications when they trigger. This skill covers reading that configuration and auditing coverage across a site.
There is no tool that returns a fired alert. The Domotz MCP server registers exactly two alert tools, and both describe configuration: domotz_alerts_profiles_list (what profiles exist) and domotz_alerts_device_list (which profiles are bound to one device).
Neither returns an alert instance, an alert ID, a severity, a timestamp, or an active/resolved state. There is no alert feed, no alert history, and no way to ask "what is alerting right now" through this integration.
That is a limit worth stating rather than working around, because the obvious workaround is wrong in a specific way. You can approximate current site health from domotz_devices_list status plus domotz_devices_history and domotz_devices_uptime — but that is device state, not alert state. It will not tell you what Domotz notified on, whether anyone acknowledged it, or whether a profile was even bound to that device. Do not present a device-status roll-up as an alert report. If the question is genuinely "what did Domotz alert on", the answer comes from the Domotz portal or the notification channel, not from here.
above. Incident queues with acknowledgement and escalation are betterstack-incidents, pagerduty-incidents, or rootly-incidents.
threshold conditions, never threat findings; use huntress-incidents.
spans tenants rather than one site, use auvik-alerts.
are created and edited in the Domotz portal.
A profile bundles a trigger condition with a notification target and a scope. Profiles are defined once at the account level and then bound to the devices they should watch, which is why coverage is a two-step question: what profiles exist, and what is each device bound to.
Typical conditions Domotz profiles cover include device online/offline transitions, SNMP threshold breaches, and new-device discovery. The exact set available depends on the Domotz plan and how the profile was built in the portal — read the profile rather than assuming.
domotz_alerts_device_list answers the per-device half: given an agent_id and device_id, which profiles apply. A device with no bindings is monitored for inventory purposes but will generate no notifications, which is the coverage gap most audits are looking for.
| Tool | Description | Arguments |
|---|---|---|
domotz_alerts_profiles_list | Every alert profile configured on the account | (none) |
domotz_alerts_device_list | Alert profile bindings for one device | agent_id, device_id |
domotz_alerts_profiles_list takes no arguments — it is account-wide, not per-agent, and cannot be filtered server-side. Both are read-only.
domotz_alerts_profiles_list to establish what profiles exist.domotz_devices_list for the agent.domotz_alerts_device_list.
profile that does not cover their failure mode.
through this integration.
Step 3 is one call per device with no batch form, so scope the audit to the devices worth auditing rather than the whole census.
domotz_alerts_device_list with the device's agent_id anddevice_id.
and inventoried but silent on failure.
domotz_alerts_profiles_list to identifywhich existing profile should cover it.
This is not an alert question against this server — it is a device-state question. Use domotz_devices_list for current ONLINE/OFFLINE status, domotz_devices_history for recent transitions, and domotz_network_ip_conflicts for addressing faults. Say explicitly that the answer is derived from device state and does not reflect what Domotz alerted on.
Cause: No profiles configured on the account, or the credential's scope does not include them. Solution: Verify in the Domotz portal. An empty list means nothing is being notified on, which is itself the finding.
Cause: Usually genuine — no profile is bound. Occasionally the wrong agent_id/device_id pair. Solution: Confirm the pair against domotz_devices_list before reporting a coverage gap.
Cause: The request assumes a fired-alert surface that does not exist. Solution: Say so plainly and offer the coverage audit or the device-state view instead. Do not synthesise alert records from device status.
PDUs — where an unnoticed failure takes the site with it
automatically bound to a profile
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.