How to connect Jamf to Claude for device management
A help desk engineer has Claude open and a serial number in hand. The answer sits in Jamf Pro, three tabs away. To connect Jamf to Claude for device management, start with an API client in Jamf. Connect it once in Elaichi. Write the restrictions. Then add Elaichi to Claude as a single custom connector. MCP (Model Context Protocol) is the open standard AI clients use to call tools. Elaichi serves it at one address, https://api.elaichi.ai/mcp, for every organization.
The order matters. Write the restrictions before the first member connects a client, because a restriction change takes effect in about two minutes. Revoking a grant, removing a member and suspending one are the exceptions: those are effective on the next call.
On a Claude Team or Enterprise plan, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors. They click Add, hover over Custom and choose Web (support.claude.com, checked October 2026). Each member then finds it under Customize > Connectors and clicks Connect to authenticate (same page, checked October 2026). Claude reaches a custom connector's remote MCP server from Anthropic's cloud, not from the user's device. That holds on every Claude client (same page, checked October 2026). The step-by-step client walkthrough lives in the Claude setup guide.
What Elaichi's Jamf connector can and cannot reach
Elaichi's jamf connector carries 29 tools. Fourteen are reads. The other 15 create, update or delete, three each for accounts, users, mobile devices, mobile device applications and computer inventory. None of the 29 sends a wipe, lock, erase, unmanage, retire or remote command.
That point defuses the fear most IT leads bring to this. It also replaces it with a different one. Jamf Pro's own API privilege list treats the frightening actions as separate privileges. Among them are Send Mobile Device Remote Wipe Command, Unmanage Mobile Devices, Send Computer Remote Wipe Command and Send Computer Unmanage Command (developer.jamf.com, checked October 2026). Those commands are not in the connector's tool surface at all.
The tool that deserves attention instead is create_a_jamf_account.
The restriction that stops a quiet admin escalation
Block the three account write tools, create_a_jamf_account among them, on every role that can reach Jamf. This is the one restriction to write first.
Jamf Pro's Create Account API endpoint defaults the new account's privilege level to ADMINISTRATOR. The endpoint requires only the Create Accounts privilege. So an API role holding just that privilege can create a full admin account (developer.jamf.com, checked October 2026). An account tool reachable from a chat window is therefore a path to a Jamf administrator, even though no wipe tool exists.
A restriction in Elaichi says which connectors and tools a role or a member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So this rule gets written on each role that reaches Jamf, including the admin role. Within a layer, a block always beats an allow. A block rule matches a tool by its name or by the operation it performs. Renaming a tool cannot slip it past the block. The reasoning behind that asymmetry is covered in why blocks match names and allows do not.
Writing the rule needs the restriction:manage permission. It also needs a plan that includes restrictions, which Gold and Black both do. A rule aimed at one person also needs restriction:override.
Hold the help desk to the fourteen read tools
There are two honest shapes for this, and they fail in opposite directions.
The first is block rules naming every Jamf write tool for the help desk role. A layer with only block rules has no allowlist, so everything the rules do not name still passes. Miss one of the 15 writes and it stays reachable.
The second is an allow rule naming the 14 read tools. An allow rule turns on the allowlist for its layer just by existing. Once the help desk role carries one, that allowlist governs the whole catalog. Every tool that no allow rule names is blocked for that role. That is stricter, and it is also the trap. The same role now needs whole-connector allow rules for every other app it uses. Otherwise Slack and Intune go dark along with Jamf's writes. An allow rule that names nothing blocks everything for its target.
Pick the allowlist when Jamf is the only app that role touches through Elaichi. Pick blocks when the role reaches several apps and you would rather maintain one list than ten. The decision generalizes. Restricting one tool versus the whole app walks through six cases of it.
One thing neither shape changes. Elaichi's jamf connector authenticates with OAuth client credentials, meaning an API client's own credentials rather than a person's sign-in. Every call through a connection uses the account that connection is bound to, whoever makes the call. So Jamf's own API role is a floor for everyone who can reach the connection. Above that floor, Elaichi restrictions separate a help desk role from an admin role. Give the API client the narrowest role the questions need. The read-only variant of that role is covered in the Jamf read-only playbook.
Why Claude's connector permissions cannot do this part
Claude connector tool permissions take one of three settings: Always allow, Needs approval or Blocked. Each applies to a whole connector, to a category of its tools or to a single tool (support.claude.com, checked October 2026). That control is real, and it cannot see individual connected apps through Elaichi.
In an Elaichi client's tool list, connected tools are never listed one by one, however few there are. The model finds a connected tool with search_tools and runs it with execute_tool. A per-tool permission set on execute_tool therefore covers every connected-tool call made through it, whatever the app. It does not cover calls made through run_code or elaichi__toolbox__execute. Setting Needs approval on execute_tool asks before every Jamf read as well as every Jamf write, because execute_tool is never marked read-only.
So per-app and per-tool control belongs in Elaichi, as restrictions. Claude's own approval prompt sits on top, as a second pair of eyes. The layering is set out in human approval for AI agent actions.
The audit query that proves both restrictions held
Filter the audit log to the Jamf connection and read the "What it did" line on every row. The audit log is the organization's record of who did what, in which app. In the console it filters by free text, category, actor, action kind and a start time. It returns 50 entries per page by default and at most 200. Passing a connection id reads one connection's activity. That is open to the connection's owner, to anyone with edit access on it, and to anyone with audit:view.
Two details save an hour of confusion:
- Connected-tool calls sit in the assistant category, not the mcp category. The mcp category holds grant actions such as an MCP client being connected. Filtering to MCP and seeing no tool calls does not mean nothing ran.
- Each connected-tool row records the acting person, the connector, the connection and the tool's advertised and catalog names. It also records the tool's classification, how approval was given, the surface, the MCP client, the outcome and what the call touched. Because Jamf sees one API client for everyone, that row is the only place the individual person appears.
The detail panel's summary sentence reads like "Using Claude, Emily Carter updated the page ... through the connection ...". Its What it did line reads Read data, Changed data or Deleted data. For an access review, export the filtered view as CSV. An export longer than 10,000 entries stops rather than saving a partial file.
Now the honest part. A call a restriction refuses writes no audit row at all, because the refusal happens before any executor runs. The evidence that a block held is therefore an absence of Changed data rows for that connection. Pair it with the restriction writes themselves, recorded as restriction.created, restriction.updated and restriction.deleted. Elaichi keeps 90 days of audit history. For longer, forward it to your own log service. Export to your own Datadog comes with the Black plan, which is launching soon. What an AI agent audit log must capture covers the fields to insist on.
An MCP client can read the log too, through elaichi__audit__list. That operation takes only a page size, a cursor and an optional connection id. It cannot filter by actor, action, category or date, so the review itself belongs in the console.
When you do not need Elaichi for Jamf in Claude
If one administrator is the only person who will ever ask, skip the second vendor. Jamf Concepts publishes an open source MCP hub, Jamf-Concepts/mcp-hub. Its quick start has the user configure their own MCP client, which then starts the server itself. Its tools include ones that change data, such as creating smart groups (github.com, checked October 2026). Running that locally against a narrow API client is a reasonable afternoon.
Jamf's own hosted MCP server at developer.jamf.com/mcp only searches Jamf's developer documentation (developer.jamf.com, checked October 2026). It does not reach a tenant's device data, so no vendor-run option answers device questions today.
The case for Elaichi starts at the second person and the second app. One address that Claude, ChatGPT and Cursor all sign into. One set of role restrictions over Jamf and everything beside it. One audit log that names the person when the app only sees an API client. Browse what else sits behind that address in the connector catalog, or see the access model in governance use cases. The wider argument lives in MCP governance. The Intune version of this playbook is Intune in Claude for help desk lookups.
