[Auvik] Verify that the configured Auvik user name and API key authenticate. This is Auvik's own purpose-built credential check — the cheapest authenticated call, with no parameters and no side effects — so it is the right first diagnostic when other Auvik tools start failing. Read the result alongside the failure you saw: a 401 elsewhere means the key itself is invalid or was regenerated, while a 403 elsewhere means the credential is fine and the Auvik user's ROLE lacks permission for that specific area (Auvik API keys inherit their user's role rather than carrying their own scopes). If this tool succeeds but another returns access-denied, the fix is a role change in Auvik, not a new key.

[Auvik] Get one tenant's detail by tenant id (ids come from auvik_list_tenants). This endpoint has no pagination.

[Auvik] List DETAIL for the tenants associated with your Auvik account — richer per-tenant information than auvik_list_tenants returns. Use auvik_list_tenants when you only need ids to scope another call; use this when you need each tenant's attributes. This endpoint has no pagination.

[Auvik] List every Auvik tenant — multi-client and client — that the configured Auvik user can reach. CALL THIS FIRST in any multi-client environment: the ids it returns are exactly what the `tenants` parameter on the other Auvik tools consumes, and Auvik REQUIRES that parameter on the four SNMP poller tools. Takes no parameters. Note that Auvik's SaaS Management tools use their own separate client ids from auvik_list_asm_clients, not these.

[Auvik] Get one device's discovery and management state by device id (from auvik_list_device_info) — per-protocol discovery status, managed/billable flag, and TrafficInsights state. Use this to diagnose why Auvik is not collecting data for a specific device.

[Auvik] Get one device's extended hardware/software details by device id (from auvik_list_device_info). Unlike the list variant this does NOT need a device type — Auvik resolves the type from the id.

[Auvik] Get one device's core inventory attributes by device id (ids come from auvik_list_device_info). Returns the raw JSON:API document for that single device. Use auvik_get_device_detail for discovery/management state, auvik_get_device_extended_detail for hardware/software specifics, and auvik_read_device_statistics for time-series metrics.

[Auvik] List device DISCOVERY and MANAGEMENT state — per-protocol credential/discovery status (SNMP, WMI, login, VMware), whether the device is billed as managed, and TrafficInsights forwarding state. This is the tool for auditing which devices Auvik can actually poll and why a device is missing data. For inventory attributes use auvik_list_device_info instead. Returns a raw JSON:API document; page forward with links.next as pageAfter.

[Auvik] List EXTENDED device details — the deeper hardware/software attributes Auvik collects beyond the basic inventory (per-type fields such as firmware/OS versions, chassis and stack members, virtualization specifics). deviceType is REQUIRED by Auvik on this endpoint: extended attributes differ per device type, so one call returns one type at a time. Use auvik_list_device_info first to learn which types exist in the environment.

[Auvik] List discovered devices with their core inventory attributes (name, IP addresses, make/model, vendor, device type, online status, serial number, last-seen time). This is the primary device discovery tool — start here to find device ids for every other Auvik device, interface, configuration, and statistics tool. Returns a raw JSON:API document {data:[...], links:{next,prev}, meta:}; page forward by passing links.next's cursor as pageAfter. Set include=deviceDetail to embed each device's discovery/management detail object in the response's `included` array.

[Auvik] List device LIFECYCLE status — vendor end-of-sale, software-maintenance, security-maintenance, and last-support milestones per device. This is the hardware-refresh planning tool: filter by 'expired' on any axis to build a replacement list. Every status filter accepts covered, available, expired, securityOnly, unpublished, or empty.

[Auvik] List collected WARRANTY and support-contract coverage per device — coverage flags plus contract/expiry information Auvik gathered from the vendor. Use it to find hardware that has fallen out of warranty or off a service contract. Pair with auvik_list_device_lifecycles for end-of-sale / end-of-support status.

[Auvik] Get one network's core attributes by network id (ids come from auvik_list_network_info). Use auvik_get_network_detail for its collector assignment and scope instead.

[Auvik] List network DETAIL — the scanning and collector configuration behind each discovered network: public vs private scope, which collector polls it (primary and secondary), how the collector was selected, and any excluded IP addresses. This is the tool for auditing scan coverage and for finding networks Auvik is not allowed to scan. For addressing and network names use auvik_list_network_info instead.

[Auvik] List the networks Auvik discovered, with their core attributes (network name, address range, network type, scan status, description). Use this to map a client's addressing and to get network ids for auvik_list_device_info's networks filter. Returns a raw JSON:API document {data:[...], links:{next,prev}, meta:}; page forward by passing links.next's cursor as pageAfter. Set include=networkDetail to embed each network's collector/scope detail object in the response's `included` array.

[Auvik] Get one interface's attributes by interface id (ids come from auvik_list_interface_info). For that interface's bandwidth, utilization or packet-loss history use auvik_read_interface_statistics.

[Auvik] List the interfaces Auvik discovered on client devices — interface name and type, parent device, administrative state, operational status, addressing, and speed. Use it to find which ports are down, which are administratively disabled, and to get interface ids for auvik_read_interface_statistics (bandwidth, utilization, packet loss). Returns a raw JSON:API document; page forward with links.next as pageAfter.

[Auvik] Get one component's attributes and current health status by component id (ids come from auvik_list_component_info). For that component's metric history use auvik_read_component_statistics.

[Auvik] List device COMPONENTS — the sub-parts Auvik monitors inside each device: CPUs and cores, disks, fans, memory, power supplies, and system boards, each with its current health status. Filtering currentStatus to failed or degraded is the hardware-fault triage path: it surfaces dying fans, failed power supplies and full disks across the whole fleet in one call. Component ids from here feed auvik_read_component_statistics for temperature and utilization history.

[Auvik] List the entity AUDIT trail — the record of remote-access sessions run against client entities through Auvik (tunnels, terminal sessions, remote browser sessions), with the user who initiated each one, its outcome, and when. This is the who-touched-what surface: use it to answer access-review questions or to correlate a change with the session that made it. Distinct from auvik_list_entity_notes, which holds written annotations rather than access events.

[Auvik] List the operator-written NOTES attached to entities — devices, networks and interfaces — with their text, the entity they annotate, who last edited them, and when. This is the human context Auvik holds about a client's infrastructure: why a device is configured a way, what a network is for, known quirks. Read it before drawing conclusions from telemetry alone.

[Auvik] Get one configuration capture by id (ids come from auvik_list_configurations), including the full configuration TEXT as Auvik stored it. Use this to diff two captures or to inspect exactly what was running on a device at a point in time. Configuration text can be long — fetch a specific id rather than looping over a whole client's history.

[Auvik] List the device configuration BACKUPS Auvik has captured — one entry per capture, with its device, backup time, and whether it is the running or a stored configuration. Use it to confirm a device is actually being backed up, to find when its config last changed, or to locate the capture immediately before an outage. This returns capture metadata; call auvik_get_configuration with an id to read the configuration text itself.

[Auvik] Dismiss a single Auvik alert. IRREVERSIBLE: Auvik exposes no un-dismiss operation, so once an alert is dismissed through the API it cannot be restored to the open queue from here — an operator would have to work with it in the Auvik console. This is the only write operation the Auvik API offers. Get the alert id from auvik_list_alerts, and read the alert first (auvik_get_alert) if there is any doubt about whether it is still relevant.

[Auvik] Search Auvik ALERT HISTORY — the alert events the collectors have raised, with severity, current status, the entity that triggered them, detection time, and whether they were dismissed or dispatched. This is the triage entry point: filter severity to emergency or critical with status=created and dismissed=false to find what still needs attention. Returns a raw JSON:API document; page forward with links.next as pageAfter.

[Auvik] Read a client's billable USAGE summary for a date window — and, for a multi-client, its children's too. This is the data Auvik invoices from, so it is the surface for reconciling an Auvik bill against what you believe you are managing, and for spotting a client whose billable device count jumped. Both dates are required. This endpoint has no pagination. For a single device's usage use auvik_read_device_usage.

[Auvik] Read one device's billable usage over a date window. Use it to answer why a specific device is (or is not) counted as billable in a period — the per-device drill-down behind auvik_read_client_usage's totals. Both dates are required. This endpoint takes no tenant scope and has no pagination.

[Auvik] Read historical COMPONENT metrics as a time series — the inside-the-box telemetry for CPUs, disks, fans, memory, power supplies and system boards. This call needs TWO path values: which kind of component (componentType) and which metric (statId). Not every metric is meaningful for every component kind — temperature suits fan and systemBoard, utilization suits cpu, disk and memory, speed suits fan. Pair with auvik_list_component_info, which reports each component's current health and supplies componentId.

[Auvik] Read historical device UPTIME or OUTAGE statistics as a time series. This is the availability/SLA surface: statId=uptime gives the up-percentage per interval, statId=outage gives the outage events. Use it for uptime reporting and for confirming whether an incident was a real outage or a polling gap.

[Auvik] Read historical DEVICE performance metrics as a time series. Pick one statistic per call via statId. Use it to answer capacity and saturation questions — is this switch's CPU pinned, is memory climbing, is a link saturated. For uptime and outage history use auvik_read_device_availability_statistics instead.

[Auvik] Read historical INTERFACE metrics as a time series — throughput, utilization, and error/loss counters per port. This is where link-saturation and packet-loss investigations happen: statId=utilization for saturation, packetLoss or packetDiscard for quality problems. Get interface ids from auvik_list_interface_info, or pass parentDevice to cover every port on one device.

[Auvik] Read the CURRENT value of numeric SNMP pollers (device monitors). Unlike every other Auvik statistics tool this is a point-in-time read, NOT a time series — it takes no time range and no interval, and returns each poller's latest value. For the historical values of a numeric poller use auvik_read_snmp_poller_int_history; for string pollers use auvik_read_snmp_poller_string_history. Poller configuration itself lives in auvik_list_snmp_poller_settings.

[Auvik] Read historical CLOUD PING CHECK statistics — the reachability probes Auvik runs against monitored services. statId=pingTime gives round-trip latency, statId=pingPacket gives packet-level results. Use it to distinguish a client-side problem from an upstream service being slow or unreachable.

[Auvik] Get one SNMP poller setting by its id (ids come from auvik_list_snmp_poller_settings) — its name, OID, value type and usage. Unlike the list variants in this group, this endpoint takes no tenant scope.

[Auvik] List the DEVICES a given SNMP poller setting applies to, with each device's online status and identifying attributes. Use it to confirm a custom poller is actually reaching the hardware you expect, or to find devices where it should apply but doesn't. Auvik REQUIRES an explicit tenant scope on this endpoint.

[Auvik] List the custom SNMP POLLER SETTINGS configured in Auvik — each one's name, the OID it polls, whether it is a string or numeric poller, and what it is used as. Start here when you need to know what bespoke SNMP data a client's Auvik is collecting. The type value decides which history tool applies afterwards: numeric pollers go to auvik_read_snmp_poller_int_history, string pollers to auvik_read_snmp_poller_string_history. Auvik REQUIRES an explicit tenant scope on this endpoint.

[Auvik] Read the historical values of NUMERIC SNMP pollers over a time range, aggregated by interval. Use this for pollers whose type is 'numeric' in auvik_list_snmp_poller_settings — temperatures, counters, custom gauges — to trend a value over time. For the current value only, auvik_read_oid_statistics is cheaper; for string pollers use auvik_read_snmp_poller_string_history (which takes no interval). Auvik REQUIRES an explicit tenant scope.

[Auvik] Read the historical values of STRING SNMP pollers over a time range. Use this for pollers whose type is 'string' in auvik_list_snmp_poller_settings — firmware versions, serial numbers, textual status fields — to see when a value changed. Note this endpoint takes NO interval (string values are not aggregated); for numeric pollers use auvik_read_snmp_poller_int_history instead. Auvik REQUIRES an explicit tenant scope.

[Auvik] List the SaaS APPLICATIONS Auvik discovered in use at a client — what is actually being signed into, when it first appeared, and (via include) its publisher, contracts, users, access data, and known breaches. This is the shadow-IT discovery surface: filter dateAddedAfter to see what appeared recently. Application ids from here are required by auvik_list_asm_licenses. Requires the Auvik SaaS Management product; an access-denied response usually means the account is not licensed for it.

[Auvik] List the clients covered by Auvik SaaS Management. CALL THIS FIRST for anything SaaS-related: the client ids it returns are what every other ASM tool's clientId parameter requires, and they are NOT the same ids as auvik_list_tenants returns. Set include=totals for per-client roll-up counts. Requires the separately-licensed Auvik SaaS Management product — an access-denied response here usually means the account is not licensed for it, and the rest of the Auvik connector is unaffected.

[Auvik] List the LICENCES assigned within one SaaS application at a client — who holds which licence type and when they last signed in. Set underutilizedOnly=true for the licence-reclamation path: it surfaces seats that are paid for but barely used, which is usually the fastest SaaS cost saving available. lastLoginBefore finds dormant accounts. Needs BOTH a client id and an application id. Requires the Auvik SaaS Management product; an access-denied response usually means the account is not licensed for it.

[Auvik] List SaaS SECURITY EVENTS Auvik recorded for a client — the security-relevant activity across their SaaS applications. Use include to embed the users and applications each event relates to so you can act on it without a second lookup. Requires the Auvik SaaS Management product; an access-denied response usually means the account is not licensed for it.

[Auvik] List the TAGS applied within a client's Auvik SaaS Management data — how the client's applications have been categorized (sanctioned, under review, and so on). Pass applicationId to see the tags on one application. Requires the Auvik SaaS Management product; an access-denied response usually means the account is not licensed for it.

[Auvik] List the SaaS USERS Auvik discovered at a client — the people whose accounts show up across the client's SaaS applications. Use it for offboarding checks (does a departed employee still hold accounts) and as the population behind licence usage. Requires the Auvik SaaS Management product; an access-denied response usually means the account is not licensed for it.