Why Jamf in Claude needs a connector
A help desk agent has a ticket open and a serial number. The answer sits in Jamf Pro: which Mac, which person, which OS build, which apps are installed. Jamf in Claude is worth setting up so that lookup happens inside the ticket, not in a second console with a second sign-in.
Jamf ships no official MCP server for a live Jamf Pro tenant. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Jamf's own MCP server searches Jamf's API documentation and returns nothing about a live fleet (developer.jamf.com, read October 2026). MCP Hub is a separate, Jamf Concepts open-source project, labeled Beta. Its own repository describes it as not an official product, meant to run locally, and shipping with write tools enabled by default (read October 2026). Neither one is a managed, multi-user path to a live tenant.
The shortcut an engineer reaches for is a local server with a Jamf token in a config file. That works for one person testing queries on a laptop. It leaves nobody able to say afterward what was queried, and nothing to change when that person moves teams or leaves. Replacing personal MCP servers covers where that shape stops holding.
The fleet path for a team is a connector that calls the Jamf Pro API on the help desk's behalf. It runs under credentials nobody on the help desk ever sees directly. Elaichi's jamf connector is one of the 600+ connectors Elaichi authors, maintains and serves from its own infrastructure. It signs in with a Jamf API client's credentials. Those credentials sit in a separate credential service, encrypted at rest, in your organization's region.
Build the Jamf API role before you connect anything
Create a dedicated API role holding only the read privileges a help desk ticket needs, then create an API client that carries that one role. The path in Jamf Pro is Settings, then System, then API Roles and Clients. An API client gets the combined privileges of every role assigned to it. So one narrow role is easier to defend in an access review than three broad ones stacked together (learn.jamf.com, read October 2026).
What to leave out, specifically:
| Privilege | Why it's excluded |
|---|---|
| Create Accounts | Creating an account through the Jamf Pro API defaults to ADMINISTRATOR privilege, so a role that can create accounts can create a full admin (developer.jamf.com, read October 2026) |
| Send Computer Remote Wipe Command | Destructive, irreversible, named explicitly in Jamf's privilege reference |
| Send Mobile Device Remote Wipe Command | Same class of risk, different device type |
| Unmanage Mobile Devices | Removes Jamf's management hooks from a device |
| Send Computer Unmanage Command | Same, for computers |
All five are named in Jamf's own privilege reference (developer.jamf.com, read October 2026). The role should hold read privileges for computer inventory, mobile devices, users and accounts. That is enough to answer "which Mac, whose it is, what's on it". It should hold nothing that creates, destroys, or remotely commands a device.
The Jamf role is the outer wall. It binds every call the client makes, including calls Elaichi never sees. If a tool somehow got past Elaichi's own restrictions, this role is what stops it from doing anything destructive at the Jamf API itself.
What the jamf connector carries, and what it leaves out
Elaichi's jamf connector exposes 25 tools total. The split, by effect on data:
| Category | Count | Examples |
|---|---|---|
| Read (GET) | 10 | list and get accounts, list and get users, list and get mobile devices, list and get mobile device apps, a mobile device search, the computer inventory list |
| Create | 5 | create_a_jamf_account, create a user, create a mobile device, create a mobile device app, create a computer inventory record |
| Update | 5 | update an account, update a user, update a mobile device, update a mobile device app, update a computer inventory record |
| Delete | 5 | delete an account, delete a user, delete a mobile device, delete a mobile device app, delete a computer inventory record |
No tool in the connector sends a wipe command, a device lock, or an unmanage command. Those commands are not in the connector at all, so the model cannot reach for one however the request is phrased. Its riskiest tools delete records and create accounts; none of them wipes a Mac.
This shapes how you plan the two layers. If the Jamf API role holds no write privileges, a write tool in Elaichi fails at Jamf's wall. The failure lands in the audit trail as an error. That is correct, but noisy, and a tool the model can find through search is a tool it may try. The cleaner shape is to make the write and delete tools invisible in Elaichi as well. The model then never offers them as an option in the first place.
One API client, many people: how restrictions narrow it
A Jamf API client authenticates with client credentials, and each token's subject is the client, not a person. Everyone calling through that one connection gets the same reach into Jamf. Jamf Pro has no concept of "this call came from help desk agent X vs. agent Y" once it is behind one API client. Narrowing per person happens in Elaichi, through restrictions: rules naming which connectors and which individual tools a role or a user may reach.
The setup for a team: an IT admin connects the Jamf API client once, then shares that connection at use with the help desk team. A shared connection runs on its owner's credential, so every agent's call reaches Jamf as that same API client. Then write a restriction against the help desk role. Custom roles are a Gold-tier feature, and one person holds exactly one role at a time. So the help desk role functions as a complete persona rather than an add-on permission.
There are two ways to write the rule, and one of them has a trap:
- Block rule names the connector's write and delete tools specifically (
create_a_jamf_accountfirst among them). It leaves the role's other connectors and tools untouched. Safe default for "hold one app to reads." - Allow rule: once a role holds even one allow rule, that rule becomes the role's entire allowlist across every connector it uses. An allow rule naming only Jamf's read tools will silently deny Zendesk, Slack, and everything else the role was supposed to reach.
Use blocks when you are restricting one app within an otherwise-open role. Use allow rules only when you are deliberately writing the role's complete approved-apps list. In that case name every connector it needs, not just the one you are thinking about right now. A block matches the tool name or its pinned operation. An allow matches the pinned operation only. The mechanics are in why blocks match tool names but allows do not.
A restriction change takes effect within about two minutes. The change applies on every surface, MCP, console and REST alike, and a withheld tool is filtered out before search runs. It never reaches the tool list, never reaches search, and its name never goes out on the wire to the model.
Add the one endpoint in Claude and let agents sign in
Claude points at one address for the whole organization: POST https://api.elaichi.ai/mcp. On Claude Team and Enterprise, an Owner or Primary Owner adds it once under Organization settings, Connectors, Add, Custom, Web. Each member then connects it individually under Customize, Connectors (support.claude.com, checked October 2026). There are no per-user URLs and no tokens to paste in. Each agent still signs in once with their own OAuth grant, the browser handshake that ties their Elaichi identity to that Claude client.
On Elaichi's consent screen, the agent ticks the scopes the client asked for. Two things worth telling them up front: "Run your connected tools" is the scope that reaches Jamf at all. Leaving "Create and change data" unticked does not make Jamf read-only. That checkbox governs Elaichi's own operations, such as editing a saved connection, not a connected app's tools. Read-only Jamf is a function of the restriction on the help desk role, not of this checkbox.
In Elaichi, connected tools are never listed one by one, however few there are. The agent asks about a serial number, the model calls search_tools, then runs the match with execute_tool. Claude's per-connector tool permissions, Always allow, Needs approval and Blocked, land on execute_tool as a single gate. One setting there covers every connected tool at once, with no per-tool granularity on Claude's side (claude.com, checked October 2026). Per-tool decisions for Jamf belong in Elaichi's restrictions, not in Claude's connector settings. The client-side walkthrough is in connecting Elaichi to Claude.
Ending access while the Jamf token is still valid
Disabling or deleting a Jamf API client does not revoke tokens that are already issued and still valid (learn.jamf.com, read October 2026). Token lifetime is configured per client. A long lifetime leaves a real window after you think you have cut access off. A token minted an hour before you disable the client can keep working until it expires on its own schedule.
This is a direct argument for keeping the credential in Elaichi rather than on a laptop. The departing agent never held the Jamf token in the first place. Cutting them off means removing the member, suspending them, or revoking the share on the connection, none of which require touching Jamf Pro itself. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision suspends the member and revokes every live grant in one action. Removing the member outright is a separate, deliberate step an admin takes in Elaichi afterward.
One thing to plan in advance: a shared connection runs on its owner's credential. If the admin who originally connected Jamf leaves the org, transfer ownership during offboarding to someone who is staying. Otherwise the whole team's Jamf access is tied to a departing person's state. The offboarding preflight lists every connection that member owns, specifically so this does not get missed. Offboarding when the agent holds access covers the rest of that checklist.
What the audit trail shows after a ticket closes
Elaichi writes one entry per tool-call attempt, succeeded or failed. Each entry names the operation and tool, the connection actually reached, and the classification. It also names whether it was approved, the outcome, and an error code if one occurred. Argument names and counts are recorded. Argument values are not. A serial number, a username, or a device ID does not land in the log itself, only the fact that one was passed.
The entry also records the surface and the OAuth client. A call from Claude shows surface mcp with Claude named and marked verified, because its redirect URIs prove it. The actor kind recorded is user, not ai_assistant: that second marker is reserved for calls made through the in-app Elaichi Agent, a different surface. Approval reads as "Allowed by the access Claude was granted," because over MCP the OAuth grant itself is the approval event, not a separate click. The trail is append-only and eventually consistent, so a row may take a short delay to appear after the call completes. A compliance reviewer can read all of this on a free Auditor seat. That seat lacks the tool:execute permission and therefore cannot call anything itself. Read access to the log does not imply write access to the fleet. For what to check in these records during a review, see what an AI agent audit log must capture.
When Jamf's own AI Assistant is the better answer
If your admins are happy working inside the Jamf console, use Jamf's built-in AI Assistant instead and stop here. It is a better fit for that specific job. It has been generally available since 31 March 2026, and it is read-only. It makes GET calls as the signed-in user, so it inherits that person's existing Jamf permissions with no second credential anywhere (learn.jamf.com, read October 2026). For a Jamf admin answering a Jamf-only question inside Jamf Pro, that is less machinery than anything described in this post.
The case for a connector is the ticket, not the device record in isolation. The agent is in Claude with the customer's message, the Zendesk history, and the device state in one place. They are not a Jamf admin with console access of their own. If one engineer only wants to test queries on their own laptop, a local server is still a better fit than an organization-wide control plane. When you do not need an MCP gateway yet draws that line explicitly. Once several people need the same reach, and somebody has to be able to prove afterward what was looked up and by whom, an MCP control plane is what you are actually buying. The connector is just the part you interact with. Browse the rest of the catalog at /connectors/, or see how other teams set this up at /use-cases/.
