)
)
At Automox, one of our favorite pastimes is asking questions, experimenting, and building things. Recently, one question kept coming up: if AI assistants can already summarize data, write scripts, and reason through complex tasks, could they also navigate the Automox console on your behalf?
That question turned into an experiment. And like most good experiments, it led to a few more, eventually resulting in a working prototype.
We built a small Model Context Protocol (MCP) server to explore how an agent might interact with Automox. The goal was to see whether an AI assistant could handle common console tasks with enough clarity and control to be genuinely useful.
The outcome of that work is the Automox MCP Server.
If this already sounds interesting and you would rather jump straight into the code, you can find the Automox MCP project on GitHub: https://github.com/AutomoxCommunity/automox-mcp
Quick note
This project is an early minimum lovable product and is still under active development, so you may encounter some rough edges or bugs. It is not a full API wrapper, but a curated set of Automox workflows designed for everyday operational tasks. Its functionality will likely evolve before a stable 1.0 release.
We are extremely excited to foster community feedback and contributions around this project. If you have suggestions for additional workflows or improvements, we would love to hear from you on the GitHub issues page:
What MCP is and why it matters
The Model Context Protocol (MCP) is a standard created by Anthropic and open-sourced in 2024. It provides a structured way for AI systems to request information, understand available tools, and take defined actions.
Before the MCP standard, every integration between an AI assistant and a product looked a little different. Each vendor defined its own plugin format, prompt conventions, and authentication patterns.
That meant the same basic ideas had to be reinvented over and over, and it was harder to reason about what an AI could do, what it should not do, and what context it had access to.
MCP creates a shared language between an AI assistant and the systems it connects to. This gives the AI the context it needs to operate safely and predictably.
Within MCP, there are two core concepts you will see within the Automox MCP Server:
Tools are actions the AI can perform. You can think of them as named operations, similar to API endpoints, such as listing devices, creating a policy, or inviting a user.
Resources are structured chunks of read-only context the AI can pull in when it needs more information, such as policy templates, schedule syntax, or server group mappings.
Authentication and Agent Scope are defined by the MCP server and the underlying system. They determine exactly which tools the assistant can access and the boundaries within which it can operate.
Because MCP is an open standard for tools and resources, anyone can implement it, which boosts interoperability, reduces vendor lock-in, and lets assistants work across ecosystems while keeping behavior transparent, auditable, and controlled.
The Automox MCP
Here is a brief summary of what the Automox MCP Server is capable of today.
Device management (6 tools)
List, search, and inspect devices with detailed information, including policy status and patch compliance. Execute immediate commands such as scan, patch, and reboot. Retrieve fleet-wide health metrics and identify devices that need attention.
Policy management (9 tools)
View, create, update, and execute Automox policies. Review policy configurations, execution history, and per-device results. Track policy health across your organization and trigger immediate remediation runs.
Account management (2 tools)
Invite users to your Automox account with role-based access control (RBAC) assignments and remove users when needed.
Audit trail (1 tool)
Retrieve audit trail events to track user activity and actions performed within your Automox organization on specific dates.
Resources in the Automox MCP Server
In addition to tools, we have also included several resources within the Automox MCP Server as part of our experimentation.
APIs are excellent for programmatic interactions, but they are not always easy for humans to interpret. Complex request bodies, nested objects, and strict formatting rules can create friction when an AI or a person tries to work with them directly.
The resource layer helps close that gap.
These resources give the MCP client structured, human-readable context that makes it easier for the AI to understand and work with the API. When we added a policy-template resource (a simplified, human-readable outline of the POST body), the AI’s accuracy improved immediately. With the structure and required fields clearly defined, it no longer needed to infer the format or rely on guesswork when generating or modifying policies.
Before this change, the create-policy endpoint’s POST body often caused errors and required multiple rounds of correction. After adding the template resource, the AI produced valid policies with far fewer iterations, often on the first attempt.
Right now, we provide several resources and expect to add more as we continue to refine the experience:
Policy template
Policy schedule syntax
Server group mappings (integer to friendly name)
Automox MCP usage examples
Below are some examples of how you can use the Automox MCP Server in its current state.
Device Health Summary
Here’s an example of how you can get a quick snapshot of device health in the console:
Show/Hide Example Code
> What can you tell me about the health of my devices in Automox?
⏺ I'll check the health of your devices in Automox by gathering aggregate health metrics.
⎿ {
"data": {
"total_devices": 51,
… +38 lines (ctrl+o to expand)
⏺ Here's a summary of your Automox device health:
Overall Fleet Health
- Total Devices: 51 (all managed)
- Compliant Devices: 41 (80.4%)
- Note: 1 compliant device is excluded from reports
Device Status Breakdown
- Ready: 42 devices (82.4%)
- Not Ready: 6 devices (11.8%) ⚠️
- Needs Reboot: 2 devices (3.9%)
- Refreshing: 1 device (2.0%)
Patching Status
- Devices with Pending Patches: 10 devices (19.6%)
- Devices Needing Attention: 6 devices ⚠️
Check-In Recency
- Last 24 hours: 45 devices (88.2%) ✓
- Last 7 days: 2 devices (3.9%)
- Last 30 days: 1 device (2.0%)
- 30+ days ago: 3 devices (5.9%) ⚠️
Key Observations
1. Good overall health: Most devices (82.4%) are ready and checking in regularly
2. Attention needed: 6 devices require immediate attention (likely the "not-ready" devices)
3. Stale check-ins: 3 devices haven't checked in for over 30 days - these may be offline or disconnected
4. Patching backlog: 10 devices have pending patches that should be addressed
Would you like me to show you which specific devices need attention, or dive deeper into any particular area?
Reboot a device
This one is simple but effective. It shows how an MCP client can be “intelligent” enough to notice two similar machines and ask which one we actually want to reboot.
Show/Hide Example Code
> Can you reboot the device "Testing box" in Automox?
⏺ I'll help you reboot the "Testing box" device in Automox. Let me first search for this device to get its ID.
⏺ automox-mcp - search_devices (MCP)(hostname_contains: "Testing box")
⎿ {
"data": {
"matches": 2,
… +48 lines (ctrl+o to expand)
⏺ I found two devices that match "Testing box":
1. HENRYSMITH8DDA (another testing box) - Device ID: 4914354
2. HENRYSMITHBB72 (Testing Box) - Device ID: 4773179
Which device would you like me to reboot?
> Device ID 4773179
⏺ I'll reboot device 4773179 (HENRYSMITHBB72 - Testing Box) now.
⏺ automox-mcp - execute_device_command (MCP)(device_id: 4773179, command_type: "reboot")
⎿ {
"data": {
"device_id": 4773179,
… +17 lines (ctrl+o to expand)
⏺ Reboot command has been successfully queued for device 4773179 (HENRYSMITHBB72 - Testing Box). The device will reboot when it next checks in with Automox.
And you can even ask it to check its work:
Show/Hide Example Code
> Did it reboot successfully?
⏺ Let me check the device details to see the status of the reboot command.
⏺ automox-mcp - device_detail (MCP)(device_id: 4773179, include_queue: true)
⎿ {
"data": {
"core": {
… +207 lines (ctrl+o to expand)
⏺ Based on the device details, the reboot command queue is currently empty ("pending_commands":[]), and the device shows:
- Last check-in: 2025-11-05 at 14:14:19 UTC
- Uptime: 132 seconds (about 2 minutes)
- Status: Compliant
The very low uptime (2 minutes) strongly suggests that the device did reboot successfully. The device has recently come back online and checked in with Automox, and the reboot command is no longer in the queue because it was executed.
Create a policy to keep Firefox up to date
The MCP server is also capable of creating patch policies (and even Worklets!)
Show/Hide Example Code
> Can you create a patch policy that keeps Firefox up to date? Make sure to include "henry" somewhere in the name of the patch policy and target the devices in the "MCP testing" group.
⏺ I'll help you create a patch policy to keep Firefox up to date. Let me first check the available resources for policy creation guidance and find the correct server group.
⏺ listMcpResources(List MCP resources from server "automox-mcp")
⎿ [
{
"name": "Policy Quick Start Templates",
… +47 lines (ctrl+o to expand)
⏺ readMcpResource(Read resource "resource://servergroups/list" from server "automox-mcp")
⎿ {
"contents": [
{
… +8 lines (ctrl+o to expand)
⏺ Great! I found the "MCP testing" group with ID 366711. Now let me get the policy creation template for a patch policy.
⏺ readMcpResource(Read resource "resource://policies/quick-start" from server "automox-mcp")
⎿ {
"contents": [
{
… +22 lines (ctrl+o to expand)
⏺ Perfect! I have the template and the server group ID. Now I'll create a patch policy for Firefox targeting the "MCP testing" group with "henry" in the name.
⏺ automox-mcp - apply_policy_changes (MCP)(operations: [{"action":"create","policy":{"name":"Auto-Patch Firefox - henry","organization_id":106820,"policy_type_name":"patch","configuration":{"filter_name":"Firefox","auto_patch":true,"aut
o_reboot":false,"notify_user":true},"schedule":{"days":["weekdays"],"time":"02:00"},"server_groups":[366711],"notes":"Automatically patches Firefox on weekdays at 2 AM for MCP testing group"}}],
preview: false)
⎿ {
"data": {
"operations": [
… +62 lines (ctrl+o to expand)
⏺ Perfect! I've successfully created a patch policy for Firefox with the following details:
Policy Created:
- Name: Auto-Patch Firefox - henry
- Type: Patch policy
- Target: MCP testing group (3 devices)
- Software: Firefox (automatically matches any Firefox installations)
- Schedule: Weekdays at 2:00 AM
- Configuration:
- Auto-patch enabled (will automatically install Firefox updates)
- Auto-reboot disabled (won't force reboots after patching)
- User notifications enabled (users will be notified about patches)
The MCP automatically handled the following:
- Converted filter_name: "Firefox" to filters: ["*Firefox*"] with wildcard matching
- Set the patch rule to "filter" mode
- Configured the full schedule with all weeks and months (will run every weekday)
The policy is now active and will keep Firefox up to date on all devices in the "MCP testing" group!
You can also have the Automox MCP modify the patch policy schedule.
Show/Hide Example Code
> Can you update the "Auto-Patch Firefox - henry" policy to only run on weekdays?
⏺ I'll help you update the "Auto-Patch Firefox - henry" policy to run only on weekdays. Let me start by finding this policy and then updating its schedule.
⏺ automox-mcp - policy_catalog (MCP)(include_inactive: false, limit: 100)
⎿ {
"data": {
"total_policies_considered": 24,
… +473 lines (ctrl+o to expand)
⏺ Found it! The policy ID is 681186. Now let me get the current policy details to see its current schedule:
⏺ automox-mcp - policy_detail (MCP)(policy_id: 681186, include_recent_runs: 3)
⎿ {
"data": {
"policy": {
… +69 lines (ctrl+o to expand)
⏺ automox-mcp - apply_policy_changes (MCP)(operations: [{"action":"update","policy_id":681186,"policy":{"schedule":{"days":["weekdays"],"time":"02:00"}}}], preview: false)
⎿ {
"data": {
"operations": [
… +130 lines (ctrl+o to expand)
⏺ Done! I've successfully updated the "Auto-Patch Firefox - henry" policy to run only on weekdays (Monday-Friday) at 2:00 AM.
Changes made:
- Previous schedule: Weekend (Saturday and Sunday) at 02:00
- New schedule: Weekdays (Monday-Friday) at 02:00
The schedule_days bitmask was changed from 192 (weekend) to 62 (weekdays). The policy will continue to automatically patch Firefox with the same settings, but now only on weekdays instead of weekends.
Checking the audit log
Let’s say you want to see what Mark Hansen has been up to over the past week in the console. The Automox MCP has a built in workflow for that also.
Show/Hide Example Code
> What did Mark Hansen do in our Automox console last week?
⏺ I'll help you find out what Mark Hansen did in the Automox console last week. Let me search the audit trail for his activity.
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-10-28", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +131 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-10-29", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +707 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-10-30", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +105 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-10-31", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +65 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-11-01", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +50 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-11-02", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +50 lines (ctrl+o to expand)
⏺ automox-mcp - audit_trail_user_activity (MCP)(actor_name: "Mark Hansen", date: "2025-11-03", limit: 100)
⎿ {
"data": {
"org_uuid": "xxxxxxxx-1b90-46fd-98d3-xxxxxxxxxxxx",
… +341 lines (ctrl+o to expand)
⏺ Based on the audit trail, here's what Mark Hansen did in the Automox console last week:
Week of Oct 28 - Nov 3, 2025
Tuesday, Oct 28
- Created 2 policies from Worklet Catalog
- Deleted 1 policy
- Ran 1 manual device scan
- Executed 1 policy run (Run Now)
- Updated 2 policy configurations
Wednesday, Oct 29 (Busiest Day - 70 events)
- Policy Management: Created 18 policies (including clones and worklets), deleted 17 policies
- Group Management: Created 1 new device group, deleted 1 group, updated group settings
- Device Operations: Ran 5 manual package installs, 5 device scans, 1 device reboot
- Policy Execution: Ran 6 policies manually (Run Now)
- Configuration: Updated 11 policy configurations, managed device tags
Thursday, Oct 30
- Created 1 policy
- Executed 4 policy runs (Run Now)
Friday, Oct 31
- Ran 1 manual package install
Monday, Nov 3
- User Management: Created 2 new users (including henry.smith+prosecurityhacker@automox.com)
- Assigned zone roles to users
- Policy Management: Created 1 policy from Worklet Catalog, updated 1 policy, deleted 2 policies
Total Activity Summary:
- Most active: Wednesday, Oct 29 with significant policy cleanup/reorganization
- Primary activities: Policy creation/deletion/updates, manual device operations, and user management
- Overall pattern suggests active testing and reorganization of policies and groups
Report generation
This example felt a bit ambitious at first, but it ended up working during testing. The Claude desktop app was used because PDF generation was part of the goal, and Claude handles that well. The organization in the example came from one of the test environments, which is why some of the policy names are on the silly side.
The whole process took about seven minutes from start to finish. A lighter model such as Haiku might speed things up, although it may return less detail. It seems like something worth experimenting with.
The output is not perfect, and that is easy to see. A few HTML tags show up where they should not, for example. Still, it feels like something that can be improved with a little more iteration.
Getting support
Although we consider this project actively maintained and community driven, it is not officially supported by Automox.
If you need help getting started, want to report a problem, or have suggestions for improvements to the Automox MCP, please open a GitHub issue in the repository.
Empowering your Workflow with AI (and Automox?)
By providing a small set of practical tools and a flexible integration framework, our goal was simply to make it easier for you to experiment with AI-driven workflows inside Automox.
There is plenty left to figure out, and we expect the project to evolve as people try new ideas and share what works. We welcome anyone who wants to explore, test, or contribute as this space continues to take shape.
Happy coding!
