Action1 RMM (unofficial)

action1-mcp-server

An unofficial Model Context Protocol (MCP) server for the Action1 RMM REST API. It lets Claude (or any other MCP host) query your Action1 fleet, run PowerShell on Windows and Bash on macOS, deploy updates, reboot endpoints, search audit trails and build CVE remediation plans, with a guard that keeps state changes off unless you switch them on.

Unofficial project. This server is not affiliated with, endorsed by,

sponsored by or supported by Action1 Corporation. "Action1" is a

trademark of Action1 Corporation. See NOTICE.

Status

Every operation of the pinned Action1 OpenAPI snapshot is reachable through a tool (see What is covered). The server speaks stdio and Streamable HTTP and ships as an MCPB bundle for Claude Desktop and as the npm package action1-mcp-server. Releases and their changes: CHANGELOG.md.

Validation status

Read this before you let an agent change anything in your fleet.

• Automated tests (npm test) run against mocked Action1 responses: unit tests, MCP protocol round trips through the SDK client, the destructive-guard truth table, redaction and size limits. Every generated tool that changes state is driven through MCP to prove it is guarded. These tests run in CI on Node 22, 24 and 26.
• Live runs against a real Action1 tenant are recorded in TESTING.md. They were made while versions 0.1 to 0.3 were developed and were not dated. They cover the read tools (organizations, endpoints, pagination, templates, missing updates), read-only script execution on Windows and macOS (action1_execute_and_wait, action1_run_script) and the guard's refusal paths.
• Read-only live shape check (2026-10-26) for 0.6.0: GET requests against a real tenant compared the returned record shapes with the vendored spec. Endpoints, vulnerabilities, installed software, automation instances and schedules, missing updates, endpoint groups and both list envelopes match the spec; audit events are still unverified (the key lacked view_audit). Details in TESTING.md. Apart from this check, the changes in 0.6.0 are covered by the automated tests only; a live smoke run of the 0.6.0 tools is pending.
• Never run against a live tenant: action1_reboot_endpoint, action1_deploy_update, action1_deploy_package, action1_uninstall_program, action1_run_data_collection, removing an endpoint from a group, action1_run_script with target_type: "EndpointGroup", every generated tool that changes state, and every account operation (users, roles, organizations, enterprise). Their request bodies follow the Action1 OpenAPI spec and are checked by tests, but nobody has confirmed that Action1 accepts them. Try them on a test endpoint first and look at the dry-run preview before you execute.

Maintenance status

• Maintained on a best-effort basis by one maintainer (@mguttmann) in spare time. The author uses it in production. There is no support contract and no guaranteed response time.
• Security fixes take priority over features. Report vulnerabilities privately (see Security).
• Dependency updates come from Dependabot; CI fails when a runtime dependency has a known high or critical advisory. A weekly job reports when Action1 serves a different API spec than the pinned snapshot.
• Only the latest minor release gets fixes.
• Issues and pull requests are welcome; see docs/CONTRIBUTING.md and the Code of Conduct.

Why this project

Action1 has a clean REST API, but a few quirks silently produce wrong results when an LLM calls it naively:

• macOS Bash actions need a ten-field run_script payload; the API answers not applicable to Mac platform for any missing field.
• Windows PowerShell actions need a non-empty success_exit_codes.
• last_seen is YYYY-MM-DD_HH-MM-SS (UTC), not ISO-8601, so Date.parse returns NaN. The server parses it and renders it readable.
• The self URL of a list item contains a /general segment that is not a real REST resource.
• Script output is interleaved with Starting / Waiting / Completed lifecycle markers that need to be filtered.
• OS is upper-case and platform lower-case, and both can carry the platform string; one detector normalises them.

The curated tools encode all of these. What the server does not cover is listed in docs/api-coverage-gaps.md.

Install

Claude Desktop: MCPB bundle (recommended)

1. Download action1-mcp- .mcpb from the project's GitHub Releases. The release workflow attaches it to every version tag.
2. Double-click it (or drag it onto Claude Desktop, or use Settings > Extensions > Install from file).
3. Fill in the wizard: API base URL of your region, organization ID, client ID and client secret, and whether destructive operations are allowed (leave this off at first).

Claude Desktop runs the bundle with its built-in Node.js. Details and troubleshooting: docs/INSTALLATION.md.

MCP Registry

The release workflow lists each stable release in the official MCP Registry as io.github.mguttmann/action1-mcp: the bundle (download URL and SHA-256 of the release asset) and, from 0.6.2 on, the npm package action1-mcp-server, both with the same environment variables. MCP hosts and directories that read the registry can install it from there. Only that name is this project; Action1 servers under other namespaces are different code.

glama.json names the maintainer of the Glama listing.

From source (any MCP host)

Requires Node.js 22.12 or newer (engines in package.json); CI tests Node 22, 24 and 26.

git clone https://github.com/mguttmann/action1-mcp.git

cd action1-mcp npm ci cp .env.example .env # fill in your Action1 credentials npm run build # compiles to dist/ (tsc only)

Attach it to Claude Code:

claude mcp add action1 -- node --env-file=$(pwd)/.env $(pwd)/dist/index.js

npm run inspector opens the MCP Inspector against the built server (needs Node 22.19 or newer). Other hosts (Claude Desktop with a JSON config, Claude.ai, Cursor, Continue.dev, Cody) are covered in docs/INSTALLATION.md.

npm (npx, any stdio MCP host)

The server is published on npm as action1-mcp-server (command action1-mcp). Only that exact name is this project. npx fetches and runs it, so no clone or build is needed; Node.js 22.12 or newer must be installed.

Attach it to Claude Code (the values land in Claude Code's own configuration; type them in your shell, never into a chat):

claude mcp add action1 \

-e ACTION1_BASE_URL=https://app.eu.action1.com/api/3.0 \ -e ACTION1_ORG_ID= \ -e ACTION1_CLIENT_ID= \ -e ACTION1_CLIENT_SECRET= \ -- npx -y action1-mcp-server

Any other stdio host takes the same command in its JSON configuration:

{

"mcpServers": { "action1": { "command": "npx", "args": ["-y", "action1-mcp-server"], "env": { "ACTION1_BASE_URL": "https://app.eu.action1.com/api/3.0", "ACTION1_ORG_ID": " ", "ACTION1_CLIENT_ID": " ", "ACTION1_CLIENT_SECRET": " " } } } }

A configuration file with these values holds the credential: keep it readable for your user only and out of version control. action1-mcp-server@ pins a version. For Claude Desktop the MCPB bundle stays the recommended path: its wizard keeps the client ID and secret in Claude Desktop's secure storage. More hosts and options: docs/INSTALLATION.md.

What is covered

• Generated tools: every operation of the pinned Action1 OpenAPI snapshot (date in src/codegen/spec/SOURCE.md) becomes a verb-first tool such as action1_list_endpoint_groups, unless a curated tool covers it. Exceptions: POST /oauth2/token is used internally and not exposed, and the two package-upload operations return an explanatory error because they need a binary body. The full mapping is generated into docs/_coverage_table.md; docs/api-coverage.md explains it.
• Curated tools for the common workflows, including high-level wrappers (CVE remediation plan, audit log search, software inventory, recurring schedules, report export, group resolver).
• Resources (action1://me, action1://orgs, action1://templates, action1://reports, action1://endpoints/{orgId}, action1://groups/{orgId}, action1://vulnerabilities/{orgId}) for hosts that pre-fetch context.
• Slash prompts for multi-step jobs (/patch-windows-fleet, /audit-vulnerabilities, /triage-offline-endpoints, /run-script-fleetwide, /software-inventory-sweep, /check-my-permissions).

tests/unit/specSha.test.ts ties the generated tools to the pinned snapshot. It does not see changes at Action1; npm run spec:check and a weekly CI job compare the snapshot with the spec Action1 serves.

Highlights

• Guarded state changes. Tools that change state need ACTION1_ALLOW_DESTRUCTIVE=true, default to a dry-run preview and need confirm: "YES" to execute. Account operations need a second switch. See Destructive guard.
• Scoping. ACTION1_ALLOWED_ORG_IDS limits which organizations the tools may address; ACTION1_TOOLSETS=read registers only read-only tools.
• Output for agents. Every read-only tool accepts response_format (markdown default, json); every tool sets all four MCP annotations and declares an outputSchema. Paginated results carry count, has_more, next_cursor, and total on the final page. Results stay under the 1 MB host limit with visible truncation notes.
• Strict inputs. Unknown or misspelled arguments are rejected with a validation error instead of being ignored.
• Auth. OAuth2 client credentials with proactive refresh, deduplicated concurrent token requests and a refresh-token fallback.
• Transport safety. Reads (GET/HEAD) are retried on network errors, HTTP 5xx and 429 (honouring Retry-After). Mutations are sent once and retried only on 429 or when the connection failed before the request was sent, so a retry never runs an action twice. Every Action1 call is bounded by ACTION1_REQUEST_TIMEOUT_MS.
• Two transports. stdio (default) and stateless Streamable HTTP, both serving MCP 2026-07-28 next to the 2025 revisions (ADR 0001). HTTP requires a bearer token, checks Host and Origin against DNS rebinding, limits bodies to 1 MB and rate-limits per client IP.
• Logs. Structured JSON lines on stderr with credential redaction, one tool_call line per call and audit lines for guarded operations. Stdout is reserved for MCP.

Architecture

+----------------------------------------------------------------------+

| Curated tools and workflow wrappers | | - script execution (Windows, macOS, OS-aware routing) | | - execute_and_wait (start + poll + filtered output) | | - get_endpoint (canonical path