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

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

Environment Variables

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.

Failure Behavior

• If a tool call fails with an authentication or connection error, check that AUVIK_API_KEY, AUVIK_BASE_URL, AUVIK_USERNAME are set and valid before assuming a data or device problem.
• On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
• For a confirmed read-only call, check connectivity and retry once if appropriate. For any call that changes state or sends a message, a timeout does not prove the action failed: inspect current state or delivery status before retrying, preserve the required approval/change gates, and do not repeat an action whose outcome is unknown.