Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/automox-mcp-server/issues.md or /mcp/automox-mcp-server/issues.json, or Pod over MCP.

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

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

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:

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:

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

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 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

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

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

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>):

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.