Reported issues for Automox MCP Server
Pod holds 23 of 42 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to Automox MCP Server.
Most discussed
Console API: spec corrections & missing docs found against a live tenant
Spec corrections and missing documentation found by exercising the Console API against a live production tenant (org 101934). Each item below is the spec vs. the observed live behavior, followed by the change requested.
Spec corrections (request/response doesn't match live)
1. POST /orgs/{orgID}/remediations/action-sets/upload — missing the required source query parameter
- Observed live: the upload requires a
sourcequery parameter (enum `generic | qualys | tenable | c
Read the thread · 2026-06-01 · closed · outside contributor · 2 comments
Build: single-device update + action-set deletes (documented-surface coverage gaps)
Closes the remaining build items from the documented-surface coverage audit (see docs/api-coverage.md). These are the documented Console API operations we want wrapped; secrets and the intentional destructive omission (DELETE /servers/{id}) are recorded in that doc and are out of scope here.
Each tool's safety tier is pre-decided per the destructive policy.
Tools to build
- **`PUT /servers/{id
Read the thread · 2026-05-31 · closed · outside contributor · 1 comment
Surface install_do_not_disturb_honored / reboot_do_not_disturb_honored in policy summary outputs (API change 2025-10-24)
Context
Per the Automox API Changelog entry of 2025-10-24, policy response bodies now include two fields:
install_do_not_disturb_honoredreboot_do_not_disturb_honored
These signal whether a given policy run respected the device's Do Not Disturb setting (for install and reboot phases separately). They show up automatically in the raw response (since the MCP doesn't strip unknown fields from policy detail), but **none of th
Read the thread · 2026-05-28 · closed · outside contributor · 1 comment
Verify v1.0.35 assign_policies_to_saved_search path against live tenant — endpoint missing from canonical OpenAPI spec
Context
Diffing the MCP server's path calls against the canonical AutomoxCommunity/openapi-defs/openapi/bundles/ax-console-bundle.yaml surfaced four MCP-only paths — endpoints the MCP server calls that don't appear in the spec at all. Three are likely stable but undocumented; one is a recent v1.0.35 addition and is the most concerning.
Critical: assign_policies_to_saved_search (v1
Read the thread · 2026-05-28 · closed · outside contributor · 4 comments
get_noncompliant_report pagination uses summary["total"] as device-count terminator
Context
Deferred from the Pass 1 bug-hunt of #65 (v1.0.28). The two non-compliant-style pagination loops in src/automox_mcp/workflows/reports.py disagree about whether summary["total"] is a device count.
get_prepatch_report (lines 155-159): explicit comment that summary["total"] is not safe as a pagination terminator:
```python
Note: summary["total"] reports pending-patch count, not device count,
so it cannot be used to short-circuit pagination. Rely on the
empty-p
Read the thread · 2026-05-27 · closed · outside contributor · 1 comment
Token budget exceeded on aggregation endpoints — design decision needed
Context
Spun off from #43 (deferred item). Surfaced during the v1.0.20 Claude Desktop test session.
Several aggregation tools (`get_patch_tuesday_readiness`, `get_compliance_snapshot`, `get_device_full_profile`, possibly others) routinely exceed the default 4000-token response budget enforced by `_apply_token_budget` in `src/automox_mcp/utils/tooling.py`. v1.0.23's #14 fix made the truncation honest (per-key `metadata.truncations` map showing total + returned per array), but the
Read the thread · 2026-05-08 · closed · outside contributor · 1 comment
Tracking: bug backlog from v1.0.20 Claude Desktop test session
Context
After shipping v1.0.20 (the official-server release that introduced the MCPB Desktop Extension install path), a Claude Desktop test session exercised four compound workflows and 16 distinct tools across 9 domains against a live tenant. The session produced a structured bug report. A second session the next morning re-ran every test and confirmed deterministic vs. transient behavior.
A stdio-transport verification harness (tests/verify_reported_bugs.py, added in #42) independently
Read the thread · 2026-04-30 · closed · outside contributor · 2 comments
Claude discovered a discrepency.
The bug
src/automox_mcp/workflows/reports.py:191 blindly assigns:
Read the thread · 2026-04-15 · closed · external user · 1 comment
Most recent
execute_device_command patch_specific sends args as an array; live API requires a string (HTTP 400)
Summary
execute_device_command with command_type="patch_specific" (InstallUpdate) can serialize the args field as a JSON array, but the live Automox device-queue endpoint requires args to be a string. An array is rejected upstream with:
{"errors":["The args must be a string."]}
(HTTP 400)
Endpoint
POST /servers/{id}/queues?o={org} with command_type_name: "InstallUpdate".
Reproduction
Queue InstallUpdate with args as an array of patch names:
`
Read the thread · 2026-06-30 · open · external user · 0 comments
Bug: list_zone_users returns empty {} for all user objects (field name mismatch)
Description
The list_zone_users tool returns the correct user count for a zone, but every user object in the results is empty {}. No user data (name, email, role, etc.) is returned.
Root Cause
In automox_mcp/workflows/account.py, the _ZONE_USER_FIELDS constant uses camelCase-style field names (firstname, lastname), but the Automox /accounts/{id}/zones/{zone_id}/users API endpoint returns snake_case fields (first_name, last_name). The _project() function finds no ma
Read the thread · 2026-06-18 · open · external user · 0 comments
discover_capabilities: make discovery runtime-aware and self-checking (diverges from callable registry)
Summary
A field reconciliation of discover_capabilities output (v2.2.1, Claude Desktop session: no-arg call + all 17 domains, script-validated against the session's exposed tool surface) confirmed the catalog is arithmetically correct — all 17 tool_count values match their list lengths, and the discovery set reconciles exactly to the registered set (133 = 132 catalog-unique + discover_capabilities; the session's 129-tool surface = 133 − 4 env-gated). But the exercise surfaced real
Read the thread · 2026-06-10 · closed · outside contributor · 0 comments
Sanitizer corrupts worklet code fields; patch policies created without filter_type (API 400)
Summary
Two bugs in the MCP server break worklet/patch-policy workflows. They were found together while creating worklets and a "patch all" policy.
Bug 1 — Response sanitizer silently corrupts code fields (display)
sanitize_for_llm / sanitize_dict (src/automox_mcp/utils/sanitize.py), applied to every tool response via as_tool_response (src/automox_mcp/utils/tooling.py), runs a markdown-link strip [text](url) -> text. This matches PowerShell type-casts:
- `$x = [bool]
Read the thread · 2026-06-08 · closed · external user · 0 comments
Account-user UUID gap: UUID-keyed account tools have no sanctioned UUID-producing listing
Problem / why
get_account_user, remove_user_from_account, and list_zones_for_user are keyed by an account-user UUID (user_id: str), but no sanctioned listing surfaces that UUID — list_users / get_user project a numeric id and deliberately omit uuid (_USER_LIST_FIELDS, workflows/account.py). So these three tools are effectively unreachable without an out-of-band UUID, which also blocks any "remove user from account" certification action (#182).
Secondary finding — fixe
Read the thread · 2026-06-08 · open · outside contributor · 0 comments
MCP App (#182 follow-up): wire API-key revocation as the access-certification act lever
Problem / why
#182 (access certification) shipped read-only — review of users/roles. The "act on a failed certification" half was deferred. Role change has no API tool (update_user is profile-only — firstname/lastname/email/tfa_type; role is set only at invite via invite_user_to_account(account_rbac_role=...)), and account membership-revoke is UUID-stranded (see the UUID-gap issue) — but API-key revocation is fully available today and numeric-keyed, so it's the one actionable revok
Read the thread · 2026-06-08 · open · outside contributor · 0 comments
Epic: MCP Apps — approval/review surfaces
Why
Ship interactive ui:// App surfaces that fill gaps a static tool response (and the console GUI) don't cover — inline review/approval before consequential writes — with graceful degradation to structured output on non-Apps hosts. Sequenced read-only → write so the safe pilot establishes the pattern first.
Constraint
prefab_ui is not installed → use the dependency-free ui:// HTML resource + AppConfig path (no Prefab Component dependency).
Sub-issues (sequenced)
Read the thread · 2026-06-08 · closed · outside contributor · 1 comment
Epic: Structured output (outputSchema) across tools
Why
Advertise a per-tool outputSchema so schema-aware MCP clients can validate our {"data","metadata"} envelopes and render them richly, and so the App surfaces (see the MCP Apps epic) can consume typed structured output. Today the envelope is attached as structuredContent, but no schema is advertised, so clients can't rely on the shape.
Phases / sub-issues
- #176 — Declare
output_schemaon the three compound tools (phase 1, zero schema conflict) - #177 — Refactor `maybe
Read the thread · 2026-06-08 · closed · outside contributor · 1 comment
MCP App: access certification (RBAC) review
Problem / why
An interactive surface to review users / roles / permissions and certify (or flag) access — a periodic security-hygiene task that benefits from an inline, reviewable UI rather than stitching together several read calls.
Scope
- Read-first review of RBAC state with optional gated changes (correct destructive tier per
docs/api-coverage.md). - Builds on the read-only triage App pattern and the structured-output schema.
- Graceful degradation to the existing tool pat
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
MCP App: remediation-apply review (gated operation)
Problem / why
Remediation-apply is among the most consequential operations the server exposes. The destructive-gating policy (docs/api-coverage.md) asks for a mitigation/confirmation on operations at this tier — and an interactive review UI is that mitigation: the operator sees exactly what will be applied before confirming. This flow gets the most design care of the App set.
Scope
- App review surface for remediation-apply, wired to the highest destructive tier's confirmation r
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
MCP App: policy change + blast-radius review
Problem / why
Policy edits can affect many devices. An interactive review that shows the blast radius — which/how many devices a proposed change would touch — before applying is a meaningful safety and UX improvement over a bare write call.
Scope
- App surface that previews the affected device set for a proposed policy change, then gates the apply (correct destructive tier per
docs/api-coverage.md). - Builds on the read-only triage App pattern and the structured-output schema.
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
MCP App: patch-approval review flow (flagship write-App)
Problem / why
The flagship interactive flow: surface pending/available patches and let an operator review-and-approve inside the App instead of issuing a blind write call. The review UI becomes an inline, reviewable confirmation step before a consequential write.
Scope
- Builds on the dependency-free App pattern from the read-only triage pilot, and on the structured-output schema work.
- Adds an
@app.tool()backend write action, gated by the existing destructive-gating tiers —
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
MCP App (read-only): non-compliant triage surface on get_compliance_snapshot
Problem / why
The MCP Apps extension lets a tool ship an interactive UI (a ui:// HTML resource + AppConfig) that hosts render inline, degrading gracefully to the structured payload on non-Apps hosts. A read-only non-compliant triage surface gives an at-a-glance, interactive view (non-compliant devices, stale devices, policy summary) the model can pull up — a useful complement to plain tool output. Starting read-only keeps it safe and dependency-light, and establishes the App patt
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
Refactor maybe_format_markdown to ToolResult so read tools can advertise outputSchema (phase 2)
Problem / why
Extending outputSchema to the read/report tools is blocked by maybe_format_markdown (src/automox_mcp/utils/tooling.py): in markdown mode it rewrites data into a markdown string, which can't satisfy a fixed object schema. So today we can't advertise an object schema while also returning markdown.
Approach
Refactor maybe_format_markdown to return a FastMCP ToolResult(content=<markdown text>, structured_content=<dict>):
- the structured object is preserved fo
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
Declare outputSchema (structured content) on the compound tools
Problem / why
MCP lets a tool advertise an outputSchema so schema-aware clients can validate results and render them richly. Our tools already return a {"data", "metadata"} envelope that FastMCP attaches as structuredContent, but we never advertise a schema — so clients can't rely on the shape. Declaring it improves client-side validation, enables typed rendering, and is the foundation App surfaces consume.
Scope — phase 1 (zero schema conflict)
Add explicit `output_schema=<sche
Read the thread · 2026-06-08 · closed · outside contributor · 0 comments
The remaining reports are on the project's issue tracker.