SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsauvik-network-alerts

auvik-network-alerts

General & other

View repository

Updated 10-15 17:21

About this skill

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.

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.