Auvik Network Alerts
Surface, filter, and triage alerts generated by the Auvik network monitoring platform. Scope by severity, status, entity (device), tenant, or time window. All operations are read-only — alert dismissal must be performed in the Auvik Dashboard.
MCP Server
- Server:
auvik-mcp (NetClaw MCP, Feature 036)
- Command:
python3 mcp-servers/auvik-mcp/auvik_mcp_server.py (stdio transport)
- Auth: Basic auth via
AUVIK_USERNAME + AUVIK_API_KEY
- Read-only: GET operations only — alert state cannot be modified through this skill
Available Tools
| Tool |
What It Does |
auvik_list_alerts |
List alert history; filter by severity, status, dismissed state, entity, time window, or alert definition; resolves device name/IP to Auvik entity ID |
Key Concepts
Tenants = MSP clients. Each managed customer is a separate Auvik tenant. Provide tenants=<name-or-domain-prefix> to scope alerts to a single client. Omit to query across all visible tenants.
Identifier resolution. The entity parameter accepts a device name, hostname, or IP address — the server resolves it to the Auvik internal entity ID. If the name matches multiple devices, the tool returns ResolutionCandidate[] so you can narrow the query.
Severity levels. Auvik alerts use five severities in descending urgency: emergency, critical, warning, info, unknown. Filter with the severity parameter.
Status values. An alert may be created (open/active), resolved, paused, or unpaused. Use status=created to see only open alerts.
Dismissed vs. active. Dismissed alerts are hidden in the Dashboard but remain in history. Use dismissed=false to exclude them (recommended for triage); dismissed=true to review what was dismissed and when.
Time windows. detected_time_after and detected_time_before accept ISO-8601 datetime strings (e.g., 2026-06-01T00:00:00Z). Use both to bound a review window for incident post-mortems.
Cursor pagination. auvik_list_alerts auto-aggregates all pages up to AUVIK_MAX_PAGES. Use fetch_all=false for incremental loading on large alert queues.
Workflow
Morning Alert Triage
- Start GAIT branch:
gait_branch with name like auvik-alert-triage-2026-06-21
- List open alerts:
auvik_list_alerts with status=created, dismissed=false
- Filter critical/emergency: add
severity=critical or severity=emergency for priority triage
- Scope to tenant: add
tenants=<client> to focus on a specific managed client
- Check device context: use
auvik-inventory (auvik_list_devices) to get device details for the alerting entity
- Record in GAIT: commit alert summary with count, top severities, and any affected devices
Investigate Alerts for a Specific Device
- Resolve device name:
auvik_list_alerts with entity=<device-name-or-IP> — the resolver identifies the entity
- Review full history: omit
status filter to see both open and resolved alerts
- Check time pattern: pass
detected_time_after=<start> + detected_time_before=<end> to narrow to a maintenance window or incident period
- Cross-reference lifecycle: use
auvik-lifecycle (auvik_list_device_lifecycle) to check if the device is EoL — recurring alerts on EoL hardware signal replacement need
- Record in GAIT: commit alert history and investigation findings
Incident Post-Mortem Alert Pull
- Define incident window: note start/end times in ISO-8601
- Pull all alerts in window:
auvik_list_alerts with detected_time_after=<start>, detected_time_before=<end>, tenants=<client>
- Review dismissed: re-run with
dismissed=true to see if any alerts were silenced during the incident
- Correlate with change records: compare alert timestamps with
servicenow-change-workflow change records
- Record in GAIT: commit post-mortem findings with alert timeline
Integration with Other Skills
| Skill |
How They Work Together |
gait-session-tracking |
Mandatory — start a branch before querying, record every turn, close with gait_log |
auvik-inventory |
Get device details and entity context for alerting assets |
auvik-lifecycle |
Correlate recurring alerts with EoL/warranty status — recurring alerts on end-of-life hardware signal refresh urgency |
auvik-performance |
After identifying alerting devices, pull performance stats to understand the conditions that triggered alerts |
servicenow-change-workflow |
Correlate alert timestamps with approved change records to confirm or rule out change-induced incidents |
Environment Variables
| Variable |
Required |
Description |
AUVIK_USERNAME |
Yes |
Auvik user email (Basic-auth username) |
AUVIK_API_KEY |
Yes |
Auvik API key (Basic-auth password) |
AUVIK_BASE_URL |
No |
Regional cluster URL; defaults to https://auvikapi.us1.my.auvik.com — swap us1 for your region |
AUVIK_VERIFY_SSL |
No |
Set false to skip TLS verification (not recommended) |
AUVIK_TIMEOUT |
No |
HTTP timeout in seconds (default: 30) |
AUVIK_MAX_PAGES |
No |
Pagination safety cap (default: 50) |
Important Rules
- Read-only — this skill cannot dismiss, acknowledge, or modify alert state. Alert management must be done in the Auvik Dashboard.
- Refer to devices by name or IP, not by Auvik entity IDs. Pass
entity=<hostname-or-IP> and let the resolver do the lookup.
- Scope to a tenant in MSP environments to avoid mixing alerts across clients.
- Do not conflate
dismissed with resolved — a dismissed alert may still indicate an unresolved condition; resolved means Auvik determined the condition cleared.
- Record every session in GAIT — triage sessions, post-mortem pulls, and investigation findings all go to the audit trail.
1---
2name: auvik-network-alerts
3description: "Surface and triage Auvik network alerts by severity, status, dismissed state, or time window across MSP tenants. Use when reviewing active alerts, investigating a specific device's alert history, filtering by severity (emergency/critical/warning), checking whether alerts are resolved or still open, or pulling alerts within a date range for incident review."
4license: Apache-2.0
5metadata:
6 { "openclaw": { "requires": { "bins": ["python3"], "env": ["AUVIK_USERNAME", "AUVIK_API_KEY", "AUVIK_BASE_URL"] } } }
7---
8
9# Auvik Network Alerts
10
11Surface, filter, and triage alerts generated by the Auvik network monitoring platform. Scope by severity, status, entity (device), tenant, or time window. All operations are read-only — alert dismissal must be performed in the Auvik Dashboard.
12
13## MCP Server
14
15- **Server**: `auvik-mcp` (NetClaw MCP, Feature 036)
16- **Command**: `python3 mcp-servers/auvik-mcp/auvik_mcp_server.py` (stdio transport)
17- **Auth**: Basic auth via `AUVIK_USERNAME` + `AUVIK_API_KEY`
18- **Read-only**: GET operations only — alert state cannot be modified through this skill
19
20## Available Tools
21
22| Tool | What It Does |
23|------|--------------|
24| `auvik_list_alerts` | List alert history; filter by severity, status, dismissed state, entity, time window, or alert definition; resolves device name/IP to Auvik entity ID |
25
26## Key Concepts
27
28**Tenants = MSP clients.** Each managed customer is a separate Auvik tenant. Provide `tenants=<name-or-domain-prefix>` to scope alerts to a single client. Omit to query across all visible tenants.
29
30**Identifier resolution.** The `entity` parameter accepts a device name, hostname, or IP address — the server resolves it to the Auvik internal entity ID. If the name matches multiple devices, the tool returns `ResolutionCandidate[]` so you can narrow the query.
31
32**Severity levels.** Auvik alerts use five severities in descending urgency: `emergency`, `critical`, `warning`, `info`, `unknown`. Filter with the `severity` parameter.
33
34**Status values.** An alert may be `created` (open/active), `resolved`, `paused`, or `unpaused`. Use `status=created` to see only open alerts.
35
36**Dismissed vs. active.** Dismissed alerts are hidden in the Dashboard but remain in history. Use `dismissed=false` to exclude them (recommended for triage); `dismissed=true` to review what was dismissed and when.
37
38**Time windows.** `detected_time_after` and `detected_time_before` accept ISO-8601 datetime strings (e.g., `2026-06-01T00:00:00Z`). Use both to bound a review window for incident post-mortems.
39
40**Cursor pagination.** `auvik_list_alerts` auto-aggregates all pages up to `AUVIK_MAX_PAGES`. Use `fetch_all=false` for incremental loading on large alert queues.
41
42## Workflow
43
44### Morning Alert Triage
45
461. **Start GAIT branch**: `gait_branch` with name like `auvik-alert-triage-2026-06-21`
472. **List open alerts**: `auvik_list_alerts` with `status=created`, `dismissed=false`
483. **Filter critical/emergency**: add `severity=critical` or `severity=emergency` for priority triage
494. **Scope to tenant**: add `tenants=<client>` to focus on a specific managed client
505. **Check device context**: use `auvik-inventory` (`auvik_list_devices`) to get device details for the alerting entity
516. **Record in GAIT**: commit alert summary with count, top severities, and any affected devices
52
53### Investigate Alerts for a Specific Device
54
551. **Resolve device name**: `auvik_list_alerts` with `entity=<device-name-or-IP>` — the resolver identifies the entity
562. **Review full history**: omit `status` filter to see both open and resolved alerts
573. **Check time pattern**: pass `detected_time_after=<start>` + `detected_time_before=<end>` to narrow to a maintenance window or incident period
584. **Cross-reference lifecycle**: use `auvik-lifecycle` (`auvik_list_device_lifecycle`) to check if the device is EoL — recurring alerts on EoL hardware signal replacement need
595. **Record in GAIT**: commit alert history and investigation findings
60
61### Incident Post-Mortem Alert Pull
62
631. **Define incident window**: note start/end times in ISO-8601
642. **Pull all alerts in window**: `auvik_list_alerts` with `detected_time_after=<start>`, `detected_time_before=<end>`, `tenants=<client>`
653. **Review dismissed**: re-run with `dismissed=true` to see if any alerts were silenced during the incident
664. **Correlate with change records**: compare alert timestamps with `servicenow-change-workflow` change records
675. **Record in GAIT**: commit post-mortem findings with alert timeline
68
69## Integration with Other Skills
70
71| Skill | How They Work Together |
72|-------|------------------------|
73| `gait-session-tracking` | **Mandatory** — start a branch before querying, record every turn, close with `gait_log` |
74| `auvik-inventory` | Get device details and entity context for alerting assets |
75| `auvik-lifecycle` | Correlate recurring alerts with EoL/warranty status — recurring alerts on end-of-life hardware signal refresh urgency |
76| `auvik-performance` | After identifying alerting devices, pull performance stats to understand the conditions that triggered alerts |
77| `servicenow-change-workflow` | Correlate alert timestamps with approved change records to confirm or rule out change-induced incidents |
78
79## Environment Variables
80
81| Variable | Required | Description |
82|----------|----------|-------------|
83| `AUVIK_USERNAME` | Yes | Auvik user email (Basic-auth username) |
84| `AUVIK_API_KEY` | Yes | Auvik API key (Basic-auth password) |
85| `AUVIK_BASE_URL` | No | Regional cluster URL; defaults to `https://auvikapi.us1.my.auvik.com` — swap `us1` for your region |
86| `AUVIK_VERIFY_SSL` | No | Set `false` to skip TLS verification (not recommended) |
87| `AUVIK_TIMEOUT` | No | HTTP timeout in seconds (default: `30`) |
88| `AUVIK_MAX_PAGES` | No | Pagination safety cap (default: `50`) |
89
90## Important Rules
91
92- **Read-only** — this skill cannot dismiss, acknowledge, or modify alert state. Alert management must be done in the Auvik Dashboard.
93- **Refer to devices by name or IP**, not by Auvik entity IDs. Pass `entity=<hostname-or-IP>` and let the resolver do the lookup.
94- **Scope to a tenant** in MSP environments to avoid mixing alerts across clients.
95- **Do not conflate `dismissed` with `resolved`** — a dismissed alert may still indicate an unresolved condition; `resolved` means Auvik determined the condition cleared.
96- **Record every session in GAIT** — triage sessions, post-mortem pulls, and investigation findings all go to the audit trail.
gabrielmoreira