Connect Jamf to Claude: Audit Device Inventory and App Data

If your team uses ChatGPT, check out our guide on connecting Jamf to ChatGPT or explore our broader architectural overview on connecting Jamf to AI Agents.

IT and DevOps teams spend countless hours inside Mobile Device Management (MDM) dashboards. Auditing device fleets, investigating non-compliant hardware, and untangling deeply nested user permissions in Jamf is a tedious operational drag. Giving a Large Language Model (LLM) like Claude the ability to read and write to your Jamf instance transforms this dynamic. Instead of clicking through five layers of Jamf Pro menus to find why a specific iOS device is failing to update, you can simply ask Claude to retrieve the device state, audit the assigned configuration profiles, and trigger a remediation workflow.

To bridge the gap between Claude and Jamf, you need a Model Context Protocol (MCP) server. This infrastructure layer translates Claude's natural language tool calls into structured REST API requests. You can spend weeks building, hosting, and maintaining this server yourself, or you can use a managed platform to dynamically generate it.

This guide breaks down the engineering complexities of the Jamf API, shows you exactly how to generate a secure Jamf MCP server using Truto, and demonstrates how to execute complex MDM workflows using Claude.

The Engineering Reality of the Jamf API

A custom MCP server is not just a lightweight proxy. It is a full integration layer that requires deep domain knowledge of the underlying vendor's architecture. The open MCP standard handles the discovery and execution protocol for the LLM, but it does nothing to abstract away the pain of the vendor API itself.

If you decide to build a custom MCP server for Jamf, you will crash into several highly specific design patterns that require significant engineering overhead.

Deeply Nested Configuration Models Jamf does not return flat, easily parseable objects. When you request a computer or mobile device, the API returns deeply nested JSON structures categorizing data into general, purchasing, userAndLocation, hardware, and operatingSystem. Writing robust JSON Schemas for Claude to comprehend these nested objects is difficult. Furthermore, updating records requires precision - you cannot simply pass a flat object back. Claude must be instructed on exactly which nested keys to target.

Idiosyncratic Data Types and Encodings Jamf enforces strict, sometimes legacy-driven data formatting rules. For example, when updating or creating mobile device applications, Jamf's app_configuration preferences must be listed using strict character entities rather than standard JSON strings. Additionally, the os_name field for Android devices is derived dynamically from the API level and cannot be explicitly set. If your custom MCP server does not enforce these rules in its schemas, Claude will confidently hallucinate invalid payloads, resulting in constant 400 Bad Request errors.

Aggressive Rate Limits and Concurrency Jamf imposes strict concurrency and rate limits to protect its infrastructure. A common mistake engineers make is assuming an integration platform will magically handle backoff for them. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When the Jamf API returns an HTTP 429 Too Many Requests error, Truto passes that error directly to the caller. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - in this case, the LLM agent framework or Claude Desktop - is fully responsible for intercepting the 429 and executing exponential backoff.

Instead of dealing with this boilerplate, Truto exposes Jamf's endpoints as clean, fully-documented MCP tools. The schemas are dynamically generated from documentation records, complete with all nested constraints and required fields.

How to Generate a Jamf MCP Server with Truto

Truto's architecture eliminates the need to hand-code tool definitions. When you connect a Jamf instance, Truto reads the integration's resource definitions and dynamically generates MCP tools based on existing documentation records. If a Jamf endpoint has no documentation record, it does not become a tool. This acts as a strict quality gate, ensuring Claude only sees well-described, schema-validated endpoints.

Every MCP server is scoped to a single integrated account and secured via a cryptographic token in the URL. You can generate this server via the Truto UI or programmatically via the API.

Method 1: Generating via the Truto UI

For ad-hoc tasks, local development, or testing Claude Desktop, the Truto UI is the fastest path.

1. Log into Truto and navigate to the integrated account page for your active Jamf connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server. You can name it, optionally restrict it to read operations to prevent Claude from accidentally wiping devices, and set an expiration date.
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Generating via the API

If you are building an AI agent product and need to generate MCP servers dynamically for your tenants, use the Truto REST API. The endpoint validates that the Jamf integration has tools available, generates the hashed token, stores it in edge KV storage for low-latency lookups, and returns the URL.

Make a POST request to /integrated-account/:id/mcp:

curl -X POST "https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp" \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jamf Security Auditor",
    "config": {
      "methods": ["read", "list"],
      "tags": ["inventory", "compliance"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response will provide the unique, self-contained URL:

{
  "id": "mcp_abc123",
  "name": "Jamf Security Auditor",
  "config": { "methods": ["read", "list"], "tags": ["inventory", "compliance"] },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This URL is all Claude needs to discover tools, authenticate, and execute requests against Jamf.

How to Connect Your Jamf MCP Server to Claude

Once you have your Truto MCP server URL, you must register it with Claude. You can do this through the Claude UI for quick access or via a manual configuration file if you are managing infrastructure locally.

Method A: Via the Claude UI

If you are using Claude on a supported tier with custom connectors enabled:

1. Open Claude and navigate to Settings -> Integrations -> Add MCP Server (or Settings -> Connectors -> Add custom connector depending on your specific Claude deployment).
2. Name your connector (e.g., "Jamf MDM").
3. Paste the Truto MCP URL into the Server URL field.
4. Click Add.

Claude will immediately ping the endpoint, execute the initialize handshake, and call tools/list to populate its context window with the available Jamf capabilities.

Method B: Via Manual Config File (Claude Desktop)

For developers using Claude Desktop locally, you must update your claude_desktop_config.json file. Because Truto provides a remote HTTP-based MCP server, you will use the standard @modelcontextprotocol/server-sse package to bridge the local standard input/output to Truto's remote Server-Sent Events (SSE) transport layer.

Open your configuration file (usually located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the following:

{
  "mcpServers": {
    "jamf-production": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_GENERATED_TOKEN"
      ]
    }
  }
}

Restart Claude Desktop. Look for the hammer icon in the input bar - this confirms that the Jamf tools have been successfully loaded and are ready to be invoked.

Hero Tools for Jamf

Truto exposes the entirety of the Jamf API, but for AI agents handling IT operations, a specific subset of operations drives the most value. Below are the highest-leverage hero tools your agent will use, complete with contextual notes and example prompts.

list_all_jamf_search_mobile_devices

Instead of paginating through thousands of devices, this tool allows Claude to execute targeted queries against the Jamf database. It requires a match parameter to filter devices, returning critical fields like id, name, serial_number, os_version, and location details.

Usage note: Instruct Claude to use specific, narrow match strings (like an exact username or serial number) to avoid hitting payload size limits on massive Jamf instances.

"Claude, search our Jamf mobile devices for any iPad assigned to 'jsmith' and tell me what OS version they are currently running."

get_single_jamf_mobile_device_by_id

Once a device ID is isolated, this tool fetches the deep, nested context required for troubleshooting. It returns the comprehensive device state, including display_name, hardware model, capacity, and active extension attributes.

Usage note: This is your primary diagnostic tool. The LLM can ingest the hardware profile and cross-reference it against known CVEs or compliance policies.

"Get the full device details for mobile device ID 1042. I need to know its exact hardware model, total storage capacity, and whether it is marked as managed."

list_all_jamf_computer_inventory

This tool handles macOS fleet management. It returns paginated Computer Inventory records, exposing the udid, general.platform, hardware.model, and management status.

Usage note: Truto normalizes the pagination for this endpoint. Claude is instructed via the tool schema to pass next_cursor values back completely unchanged, preventing token hallucination during massive fleet audits.

"Pull the first 50 computer inventory records from Jamf. Check the 'general.platform' field for each and flag any machines that are not running the latest approved macOS version."

update_a_jamf_mobile_device_application_by_id

This is a write-heavy tool used for deploying or modifying app configurations on enrolled devices. It allows updates to scoping, Self Service settings, and VPP configuration.

Usage note: The app_configuration preferences must be formatted with character entities. The dynamically generated tool schema enforces this, but you should prompt Claude explicitly to adhere to the schema's formatting rules when updating app configs.

"Update the Jamf mobile device application ID 88. Change the deployment scope to include the 'Engineering Beta' user group and ensure the app is visible in Self Service."

list_all_jamf_users

This tool retrieves the user directory from Jamf. It returns an array of user items, including their id, name, and total record size.

Usage note: Useful for reconciling HR identity data against active MDM profiles to spot shadow IT or offboarding failures.

"List all active users in Jamf. Compare this list against the offboarded employees list I provided earlier and highlight any users who still have active Jamf accounts."

get_single_jamf_user_by_id

Fetches exhaustive details about a specific Jamf user. The payload includes position, ldap_server, extension_attributes, and links to related hardware assets.

Usage note: If Claude needs to know exactly what hardware is assigned to a specific engineer, it will call this tool first, parse the related asset links, and then query the device APIs.

"Retrieve the full profile for user ID 405. Identify their LDAP server mapping and list the serial numbers of all computers and mobile devices currently assigned to them."

For the complete tool inventory, including account provisioning, VPP management, and custom object routing, review the Jamf integration page.

Workflows in Action

Connecting Jamf to Claude transforms linear, multi-click administrative tasks into dynamic, natural language workflows. Here is how a DevOps engineer or IT admin interacts with the agent in the real world.

Scenario 1: Unmanaged Device Discovery and Audit

IT teams routinely need to hunt down rogue or unmanaged hardware that is still authenticating to corporate networks. Instead of running complex SQL reports or exporting CSVs from Jamf Pro, you simply ask Claude.

"Audit the mobile device inventory. Find all devices that belong to the Sales department but currently have their 'managed' status set to false. Give me a table of the device names, serial numbers, and the last known user."

Step-by-step execution:

1. Claude calls list_all_jamf_search_mobile_devices passing a match parameter scoped to "Sales".
2. It analyzes the returned JSON array, isolating objects where the managed boolean is false.
3. For any device missing granular user data in the summary list, Claude calls get_single_jamf_mobile_device_by_id to extract the deeply nested location and user context.
4. Claude synthesizes the data and outputs a clean markdown table of rogue devices.

Scenario 2: Zero-Touch Employee Offboarding

When an employee is terminated, IT must immediately audit what hardware they possess, wipe the devices, and remove their access. Claude orchestrates this data gathering instantly.

"We are offboarding Alex Chen. Find their Jamf user profile, list every piece of hardware assigned to them, check the OS version on those devices, and prepare the exact device IDs I need to target for a remote wipe."

Step-by-step execution:

1. Claude calls list_all_jamf_users (or search, if configured) to locate Alex Chen and retrieve their id.
2. Claude calls get_single_jamf_user_by_id using the retrieved ID. It parses the links array to find all assigned computers and mobile devices.
3. Claude loops through get_single_jamf_mobile_device_by_id and get_single_jamf_computer_inventory_by_id for every piece of hardware found to verify its current OS and connectivity state.
4. It presents the IT admin with a final summary and explicitly lists the Jamf device IDs required to trigger the wipe commands.

Security and Access Control

Giving an LLM access to an MDM platform is a significant security decision. Jamf contains highly sensitive location data, PII, and full control over corporate hardware. Truto provides four distinct mechanisms to lock down your MCP servers and prevent disastrous AI hallucinations.

• Method Filtering: You can explicitly configure the MCP server to only allow specific HTTP methods. By setting config.methods to ["read"] during creation, you completely disable create, update, and delete tools. The LLM physically cannot alter Jamf state.
• Tag Filtering: Integration resources are grouped by functional tags. You can restrict the MCP server by setting config.tags to ["inventory"] or ["directory"], ensuring Claude only has access to specific domains and cannot touch app configurations or VPP assignments.
• Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL is enough to connect. For high-security environments, setting this flag requires the caller to also pass a valid Truto API token in the Authorization header. This ensures the MCP server URL cannot be abused if it leaks in a log file.
• Time-to-Live (expires_at): For temporary auditing or contractor access, you can set a strict expiration timestamp on the server. Truto enforces this using edge KV expirations and Durable Object alarms, automatically destroying the token and DB record when time expires.

Summary

Integrating Claude with Jamf replaces static MDM dashboards with conversational, intelligent automation. By leveraging Truto to auto-generate a secure, pagination-aware MCP server, you bypass the massive engineering overhead of translating Claude's tool calls into Jamf's legacy API quirks.

Your engineers do not need to write and maintain massive JSON schemas for Jamf extension attributes, nor do they need to manage OAuth token lifecycles. They just connect the account, generate the URL, and start automating IT operations.