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

1. Start GAIT branch: gait_branch with name like auvik-alert-triage-2026-06-21
2. List open alerts: auvik_list_alerts with status=created, dismissed=false
3. Filter critical/emergency: add severity=critical or severity=emergency for priority triage
4. Scope to tenant: add tenants=<client> to focus on a specific managed client
5. Check device context: use auvik-inventory (auvik_list_devices) to get device details for the alerting entity
6. Record in GAIT: commit alert summary with count, top severities, and any affected devices

Investigate Alerts for a Specific Device

1. Resolve device name: auvik_list_alerts with entity=<device-name-or-IP> — the resolver identifies the entity
2. Review full history: omit status filter to see both open and resolved alerts
3. Check time pattern: pass detected_time_after=<start> + detected_time_before=<end> to narrow to a maintenance window or incident period
4. 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
5. Record in GAIT: commit alert history and investigation findings

Incident Post-Mortem Alert Pull

1. Define incident window: note start/end times in ISO-8601
2. Pull all alerts in window: auvik_list_alerts with detected_time_after=<start>, detected_time_before=<end>, tenants=<client>
3. Review dismissed: re-run with dismissed=true to see if any alerts were silenced during the incident
4. Correlate with change records: compare alert timestamps with servicenow-change-workflow change records
5. 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.