Connect Kandji to Claude: Automate MDM Workflows

If you manage a fleet of Apple devices, Kandji holds your most valuable IT telemetry. When an incident occurs - say, a zero-day vulnerability requires you to audit installed applications across your entire macOS fleet - querying that data means either clicking through the Kandji dashboard manually or writing custom Python scripts against their API. Both approaches are slow, manual, and prone to error.

With Anthropic's native support for the Model Context Protocol (MCP), you can give Claude direct access to your Kandji tenant. You can literally ask Claude to "find all Macs missing the latest OS update and list their assigned users," and the model will execute the necessary API calls to fetch the answer.

Connecting Claude to Kandji requires an MCP server to translate the LLM's natural language requests into structured REST API calls. You could build and host a custom MCP server yourself, but then you are on the hook for managing Kandji's strict 10,000 requests-per-hour rate limit, handling pagination cursors, and writing comprehensive JSON schemas for every endpoint.

This guide shows you how to use Truto to instantly generate a managed MCP server for Kandji, connect it to Claude (if you use OpenAI, see our guide for connecting Kandji to ChatGPT), and execute complex device health and compliance audits using five core tools: list_devices, get_device, list_applications, list_device_activity, and list_parameters.

The Architectural Reality of the Kandji API

An MCP server acts as a translation layer between an LLM and an external API. It defines the available tools, accepts natural language requests, and executes structured JSON-RPC calls.

Before wiring up an AI agent to a Mobile Device Management (MDM) platform, you have to understand the shape of the underlying API. Kandji's API is highly capable but heavily structured. It enforces a strict tenant-level rate limit of 10,000 requests per hour and 50 requests per second.

If you unleash a naive AI agent on your Kandji instance and ask it to "audit all 5,000 devices," the LLM will likely attempt to loop through individual endpoints, hit the rate limit instantly, and break your production IT workflows.

Building a custom MCP server to handle this is an engineering sinkhole. You have to:

• Write a JSON-RPC 2.0 protocol handler from scratch.
• Manage the bearer token lifecycle securely.
• Write exhaustive JSON schemas for every query parameter and response body.
• Teach the LLM how to handle Kandji's specific pagination logic.

If Kandji updates an endpoint or adds a new parameter, your hardcoded schema breaks, and Claude starts hallucinating arguments.

How Truto's Managed MCP Server Works

Instead of hand-coding tool definitions, Truto's MCP server derives them dynamically.

When you connect a Kandji account, Truto maps the integration's resources to API endpoints and uses internal documentation records to generate human-readable descriptions and JSON schemas. A tool only appears in the MCP server if it has a corresponding documentation entry. This acts as a quality gate, ensuring only well-documented endpoints are exposed to the LLM.

When Claude calls a tool, all arguments arrive as a single flat JSON object. Truto automatically splits these into query parameters and body parameters based on the underlying API schemas, injects the necessary pagination instructions (like telling the LLM exactly how to handle limit and next_cursor), and executes the call against Kandji.

sequenceDiagram
    participant User
    participant Claude
    participant Truto MCP Server
    participant Kandji API

    User->>Claude: "Find all Macs missing OS update"<br>Claude evaluates available tools
    Claude->>Truto MCP Server: JSON-RPC tools/call<br>(list_devices)
    Truto MCP Server->>Kandji API: GET /api/v1/devices
    Kandji API-->>Truto MCP Server: 200 OK<br>(Device List JSON)
    Truto MCP Server-->>Claude: JSON-RPC Result<br>(Formatted text)
    Claude->>User: "Here are the 14 devices<br>needing updates..."

Each MCP server is scoped to a single connected instance of Kandji. The server URL contains a cryptographic token that encodes which account to use and what tools to expose. The URL alone is enough to authenticate and serve tools, meaning no extra configuration is needed inside Claude.

Step-by-Step: Connecting Kandji to Claude

Here is exactly how to generate your managed MCP server and connect it to Claude Desktop or Claude Web.

Step 1: Generate a Kandji API Token

Kandji uses tenant-level bearer tokens to control access to the API. We highly recommend creating a dedicated service user for this token to prevent unexpected issues if an admin leaves the company.

1. Log in to your Kandji tenant and navigate to Settings.
2. Click Access in the top navigation bar.
3. Scroll down to the API Token section and click Add Token.
4. Give the token a descriptive name (e.g., "Claude MCP Integration") and click Create.
5. Copy the token immediately - you will not be able to see it again.
6. Click Configure to manage API permissions. Ensure you grant access to device details, device lists, and device parameters.

Step 2: Create the Integrated Account in Truto

Next, you need to securely store this credential in Truto. This creates an "Integrated Account" - a connected instance of Kandji tied to your specific tenant.

You can do this via the Truto dashboard or programmatically via the API. Truto will securely vault the bearer token and handle all future authentication headers automatically.

Step 3: Generate the MCP Server URL

Once the account is connected, you generate the MCP server endpoint. You can do this from the Truto UI or via the API.

Via the Truto UI:

1. Navigate to the integrated account page for your Kandji connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (name, allowed methods, expiry, etc.).
5. Copy the generated MCP server URL.

Via the API:

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Kandji Read-Only Audit Server",
    "config": {
      "methods": ["read"]
    }
  }'

The API will return a JSON payload containing your unique, cryptographically signed MCP URL:

{
  "id": "abc-123",
  "name": "Kandji Read-Only Audit Server",
  "config": { "methods": ["read"] },
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Step 4: Configure Claude's Custom Connector

Now, you simply hand this URL to Claude.

For Claude Desktop or Individual Web Users:

1. Open Claude and navigate to Settings > Connectors.
2. Scroll to the bottom and click Add custom connector.
3. Paste your Truto MCP URL into the Server URL field.
4. Click Add.

For Team and Enterprise Plans: An organization Owner or Primary Owner must add the custom connector at the organization level first. Once added, individual members can navigate to their Connectors settings and click "Connect" to authenticate and start using it.

The Kandji MCP Tool Inventory

Once connected, Truto automatically exposes the following Kandji endpoints as callable tools for Claude. The full list of available tools and their descriptions is documented on the Kandji integration page. Because Truto normalizes the schema, Claude knows exactly what query parameters are required and how to format the request.

1. list_devices

• Description: Lists all devices managed by Kandji. Returns core details including device name, model, OS version, serial number, blueprint name, and last enrollment status.
• Example Claude Prompt: "Pull a list of all devices in Kandji and group them by their current OS version. Flag any devices running a macOS version older than 14.2."

2. get_device

• Description: Retrieves highly detailed information for a specific device. This includes deep security settings, FileVault status, MDM enrollment status, and installed agent details.
• Example Claude Prompt: "Look up the device with serial number C02X1234ABCD. Check if FileVault is currently enabled and verify its last check-in time."

3. list_applications

• Description: Lists all applications installed on a specific device managed by Kandji. This is the primary tool for software audits and vulnerability hunting.
• Example Claude Prompt: "Get the device ID for the MacBook assigned to Sarah Jenkins. Then, list all applications installed on that device and check if the Zoom client is below version 5.17."

4. list_device_activity

• Description: Retrieves a timeline of recent activities, command executions, and status changes for a specific device.
• Example Claude Prompt: "Check the activity logs for device ID 11f4eb9a-10ed-4c3d-a7c1-fb87f95743fb over the last 48 hours. Did the recent OS update command succeed or fail?"

5. list_parameters

• Description: Lists all parameters and library items assigned to a specific device via its Blueprint. Useful for verifying that specific compliance controls are actively applied.
• Example Claude Prompt: "List the parameters applied to John's MacBook. Verify that the screen lock timeout policy is set to 5 minutes or less."

Real-World Use Case: The Zero-Day Audit

Let's look at how this architecture behaves in production. Imagine a critical vulnerability is announced for a specific developer tool, and your security team needs immediate confirmation of which machines have the vulnerable version installed.

Instead of writing a Python script to handle pagination and rate limits, you simply open Claude and type:

"We need to audit our fleet for a vulnerable version of Docker Desktop. Please use Kandji to list all our macOS devices. For each device, check the installed applications. Give me a markdown table of any device running a version of Docker Desktop older than 4.28.0, including the device owner and serial number."

Here is what happens under the hood:

1. Claude reads the prompt and selects the list_devices tool.
2. Truto receives the JSON-RPC call, formats the GET request, and handles the authentication header.
3. Claude receives the list of devices. Recognizing it needs application data, it iterates through the device IDs, calling the list_applications tool for each one.
4. Truto proxies these requests to Kandji. If the list of applications is long, Truto's injected next_cursor instructions ensure Claude correctly requests the next page of results.
5. Claude parses the JSON responses, identifies the outdated software versions, and generates the requested markdown table.

You get an accurate, real-time audit report in minutes, entirely driven by natural language.

Security and Access Control

When connecting an AI to your MDM, security cannot be an afterthought. Truto provides multiple layers of defense to ensure your MCP implementation remains secure.

• Method Filtering: As shown in the setup steps, you can restrict the MCP server token to only allow read operations. This physically prevents the LLM from executing create, update, or delete methods, neutralizing the risk of accidental device wipes or configuration changes.
• Tag Filtering: You can restrict the MCP server to specific functional areas using tags. For example, you could expose only the devices and applications endpoints, while hiding the blueprints or users endpoints entirely.
• API Token Auth Layer: By default, possessing the MCP URL is enough to call the tools. For enterprise environments, you can enable require_api_token_auth: true when generating the MCP server. This forces the MCP client (Claude) to also provide a valid Truto API token in the Authorization header, adding a second layer of identity verification.
• Ephemeral Access: You can create MCP servers with a strict time-to-live by passing an expires_at timestamp. Once the timestamp passes, Truto automatically destroys the token and schedules a cleanup alarm, ensuring no stale access remains.

Moving Beyond Manual Audits

The era of clicking through ten different SaaS dashboards to complete an IT audit is ending. By connecting Claude directly to Kandji via a managed MCP server, you transform your MDM platform from a static database into an interactive, agentic tool.

You avoid the maintenance nightmare of building custom integrations, sidestep the complexity of vendor rate limits, and give your IT team the ability to query fleet telemetry at the speed of thought.