gabrielmoreira 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_branchwith name likeauvik-alert-triage-2026-06-21 - List open alerts:
auvik_list_alertswithstatus=created,dismissed=false - Filter critical/emergency: add
severity=criticalorseverity=emergencyfor 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_alertswithentity=<device-name-or-IP>— the resolver identifies the entity - Review full history: omit
statusfilter 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_alertswithdetected_time_after=<start>,detected_time_before=<end>,tenants=<client> - Review dismissed: re-run with
dismissed=trueto see if any alerts were silenced during the incident - Correlate with change records: compare alert timestamps with
servicenow-change-workflowchange 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
dismissedwithresolved— a dismissed alert may still indicate an unresolved condition;resolvedmeans Auvik determined the condition cleared. - Record every session in GAIT — triage sessions, post-mortem pulls, and investigation findings all go to the audit trail.