Skip to main content
Iru provides AI agent tools for device management and information retrieval. Reference these tools in using @ mentions to enable automated device troubleshooting and diagnostics.

​
Look up devices

Find devices

Search for devices in Kandji using serial number, MAC address, device name, model, platform, or user name. The tool automatically includes the requesting user’s email as a fallback search parameter and may return multiple matching devices. Use it to get the device ID before calling any other Iru tool.Tool name: @Find DevicesInput fields:
  • serialNumber - device serial number.
  • macAddress - device MAC address, for example 00:0c:29:05:43:b6.
  • deviceName - device name to search for.
  • model - device model, for example MacBook Air or iPhone 15.
  • platforms - one or more platforms to filter by: Mac, iPad, iPhone, AppleTV, Android, Windows.
  • user - name of the device owner, for example Art Vandelay.
Output data:
  • devices - array of matching devices. Each device includes deviceId, deviceName, serialNumber, model, platform, osVersion, lastCheckIn, user (email and name), assetTag, blueprintName, mdmEnabled, agentInstalled, and tags.
Common use cases:
  • Find all devices assigned to a user
  • Look up a device by serial number before running a remote action
  • Filter devices by platform to scope a compliance review
  • Identify a device by name when a serial number is not available
Example rule:

When a user asks about their devices, use @Find Devices to search by their name. If they mention a serial number or device name, include it in the search. Summarize each device found: model, OS version, and last check-in time.

Get comprehensive device information from Kandji for a single device. Covers hardware, MDM status, disk encryption, network, recovery information, installed configuration profiles, and local user accounts. Requires a device ID from @Find Devices.Tool name: @Get Device DetailsInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
Output data:
  • iruDeviceDetails - a device detail object with sections: general (model, OS, assigned user, blueprint), mdm (enabled status, supervision, last check-in), activationLock, filevault (encryption status, key escrow), kandjiAgent (version, last check-in), hardwareOverview (processor, memory, serial number), volumes (disk usage and encryption), network (MAC address, IP addresses), recoveryInformation (recovery lock, firmware password), securityInformation (remote desktop), users (local accounts), installedProfiles, and tags.
Common use cases:
  • Retrieve hardware specs and serial number for an asset record
  • Check FileVault status and whether the recovery key is escrowed
  • Confirm configuration profiles are installed on a device
  • Look up the device’s current network address
Example rule:

When a user asks for details about a specific device, use @Find Devices to locate it, then use @Get Device Details to return hardware information, MDM status, and installed profiles. Highlight any issues such as disabled MDM or missing FileVault encryption.

Get the list of apps installed on a device. Returns the name, bundle ID, version, and source for each app. For iPhone and iPad devices, preinstalled Apple apps are not included. Requires a device ID from @Find Devices.Tool name: @Get Device AppsInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
Output data:
  • apps - array of installed apps. Each app includes appName, bundleId, version, source, and path.
Common use cases:
  • Verify whether a required app is installed before approving access
  • Check which version of an app a user is running
  • Audit apps on a device flagged in a security review
Example rule:

When a user asks whether a specific app is installed on their device, use @Find Devices to locate the device, then use @Get Device Apps to check. Report the app name and version if found, or confirm it is not installed.

Get a paginated list of events on a device, such as enrollments, MDM command results, name changes, and blueprint updates. Requires a device ID from @Find Devices.Tool name: @Get Device ActivityInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
  • limit - maximum number of items to return. Defaults to 50 and cannot exceed 50.
  • offset - number of items to skip for pagination.
Output data:
  • iruDeviceActivities - array of activity items. Each item includes actionType, createdAt, details, computer (device name at the time of the event), blueprint, and user (who performed the action).
  • totalCount - total number of activity events on the device.
  • limit, offset - the values used for this page of results.
Common use cases:
  • Review recent MDM commands sent to a device
  • Check when a device was enrolled or re-enrolled
  • Identify who changed a device’s blueprint or name
  • Audit device history during a security review
Example rule:

When a user asks what has happened recently on their device, use @Find Devices to locate it, then use @Get Device Activity to return the most recent events. Summarize the action types and dates in the reply.

Get the compliance and installation status of a device’s assigned library items and security parameters. Library items represent apps, scripts, and configuration profiles managed by a blueprint. Requires a device ID from @Find Devices.Tool name: @Get Device StatusInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
Output data:
  • libraryItems - each item’s name, type, status, reportedAt, and log.
  • parameters - each security parameter’s name, category, subcategory, and status.
Common use cases:
  • Check whether required apps and scripts are installed and passing
  • Identify failing compliance parameters before an access approval
  • Review the status of all configuration profiles on a device
  • Confirm a device meets security requirements
Example rule:

When a user reports a compliance issue or is denied access, use @Find Devices to locate their device, then use @Get Device Status to check library item and security parameter status. List any items that are failing or pending and describe next steps.

​
Troubleshoot devices

Triggers an immediate daily check-in on a device. For Apple devices, this runs the daily MDM commands and Kandji-managed logic. For Windows devices, this initiates a full daily CSP sync. Requires a device ID from @Find Devices.Tool name: @Perform Daily Check-inInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
Common use cases:
  • Force a compliance remediation to run without waiting for the next scheduled check-in
  • Apply a blueprint change to a device right away
  • Resolve a pending policy application for a Windows device
Example rule:

When a user says their device is not picking up a recent policy or compliance change, use @Find Devices to locate the device, then use @Perform Daily Check-in to trigger an immediate check-in. Tell them to allow a few minutes for the changes to apply.

Sends a blank MDM push notification to a device, prompting it to check in with the Kandji MDM server. Use it to troubleshoot MDM connectivity or force the device to pick up pending commands. Requires a device ID from @Find Devices.Tool name: @Send Blank PushInput fields:
  • iruDeviceId (required) - the Kandji device ID, obtained from @Find Devices.
Common use cases:
  • Wake a device that has not checked in recently
  • Force a device to pick up a stuck MDM command
  • Verify MDM connectivity is working
Example rule:

When a device has not checked in and MDM commands are stuck, use @Find Devices to locate the device, then use @Send Blank Push to prompt it to reconnect. Follow up by checking @Get Device Activity to confirm the check-in arrived.

A tool with no execution policy set runs without asking. When Copilot drafts a rule, it suggests Requires confirmation for write tools and Requires approval for delete tools, and you can change either per rule. See tool execution policies.

​
Setup

1

Install Iru integration

Follow the Iru setup guide to connect your Iru instance to Ravenna.
2

Configure agent

Navigate to your agent’s settings and ensure Iru tools appear in the Tools section under Capabilities.
3

Create rules

Write that reference Iru tools using @ mentions.
4

Test tools

Test your rules in a controlled environment to verify tools work as expected.

​
Best practices

  • Find the device first. All tools except @Find Devices require a device ID. Have the agent call @Find Devices before any other Iru tool, and confirm the right device when multiple results come back.
  • Chain read tools before write tools. Use @Get Device Status or @Get Device Details to confirm a device’s state before triggering @Perform Daily Check-in or @Send Blank Push.
  • Use compliance status to gate access approvals. Call @Get Device Status as part of an access request workflow to check that required library items are passing before approving.
  • Check management status before troubleshooting. Use @Get Device Details to confirm MDM is enabled and the Kandji agent is installed before suggesting remediation steps.
  • Prefer @Perform Daily Check-in over @Send Blank Push for policy gaps. A daily check-in applies the full Kandji logic; a blank push only prompts the device to call home, which is useful for connectivity issues but does not re-run policies on its own.
Learn more about configuring agents and writing effective rules
Last modified on September 29, 2026