# 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](/mcp/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 **`source` query parameter** (enum `generic | qualys | tenable | c [Read the thread](https://github.com/AutomoxCommunity/automox-mcp/issues/131) · 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`](https://github.com/AutomoxCommunity/automox-mcp/blob/main/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](https://github.com/AutomoxCommunity/automox-mcp/issues/111) · 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](https://docs.automox.com/product/Developer/What_s_New.htm), policy response bodies now include two fields: - `install_do_not_disturb_honored` - `reboot_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](https://github.com/AutomoxCommunity/automox-mcp/issues/90) · 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`](https://github.com/AutomoxCommunity/openapi-defs/blob/main/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](https://github.com/AutomoxCommunity/automox-mcp/issues/86) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/68) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/53) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/43) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/28) · 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: ```json {"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](https://github.com/AutomoxCommunity/automox-mcp/issues/234) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/226) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/217) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/206) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/193) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/192) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/184) · 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_schema` on the three compound tools (phase 1, zero schema conflict) - [ ] #177 — Refactor `maybe [Read the thread](https://github.com/AutomoxCommunity/automox-mcp/issues/183) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/182) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/181) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/180) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/179) · 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](https://github.com/AutomoxCommunity/automox-mcp/issues/178) · 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=, structured_content=)`: - the structured object is preserved fo [Read the thread](https://github.com/AutomoxCommunity/automox-mcp/issues/177) · 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=