# Reported issues for Box Admin Analytics MCP

Pod holds 6 of 6 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 [Box Admin Analytics MCP](/mcp/box-admin-analytics-mcp).

## Most discussed

### get_user: split the permission hint so a 401 is not diagnosed as a missing scope

Follow-up to the advisory finding on #59 (ai-review R1F1).

`_user_lookup_hint()` fires on both `HTTP 403` and `HTTP 401`, and since #59 its text asserts the verified 403 diagnosis (missing "Manage users" application scope, fix by granting + re-authorising). That diagnosis was verified for 403 specifically; a 401 can also mean a stale/revoked access token, where the right first step is simply re-authenticating, not touching scopes.

Possible refinement: split the hint — keep the scope diagnosis 

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/60) · 2026-08-20 · open · 0 comments

### Add a per-user lookup — account status is not reachable at all today

## Problem

There is no way to ask about **one** user. All seven tools read `admin_logs`, so the closest
thing to "what is this account's state?" is inferring it from events — which only works if an
event happens to be in the window being queried.

The concrete case: a helpdesk ticket that says, in full, *"my Box account is disabled"*. The
submitter's address is known and verified. Answering it needs one lookup of that account's
status. Today the server cannot do it, so the reply has to ask the 

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/47) · 2026-08-14 · closed · 0 comments

### Add a live smoke test that exercises every registered tool

## Motivation

Unit tests check logic against fixtures. They cannot tell you that a tool users actually call has stopped returning real data — a tool that exists but does not work is worse than no tool.

This happened for real in `jquants-mcp`: the earnings-calendar tools returned well-formed **empty** results for every query while the whole suite stayed green (shigechika/jquants-mcp#523). A live smoke test was built there to close the gap, and on its first production run it found three defects,

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/23) · 2026-07-25 · closed · 0 comments

### resilience: bound scan/request wall-clock under sustained throttle (scan-level deadline + per-request timeout)

## Context

PR #12 (closing #11) added retry/backoff to the read path (`_FolderReadMixin._get`) and, crucially, a **per-call wall-clock budget** (`_MAX_RETRY_ELAPSED`) so a sustained 429/5xx or a hung endpoint fails fast instead of blocking long enough to hard-time-out the whole tool call.

Adversarial review of that fix surfaced two **residuals that the per-call budget does not cover**. Both were left out of PR #12 on purpose (documented in a code comment in `client.py`) because each is a large

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/13) · 2026-07-11 · closed · 0 comments

### resilience: retry 429/transient errors with Retry-After + jittered backoff in the request path (client._get)

## Problem

`BoxClient._get` / `BoxOAuthClient._get` (the shared read path behind every folder/collaboration/items call) retries **only on 401** (token re-auth). Any other non-2xx — including **429 Too Many Requests** and transient **5xx** — is raised immediately as `BoxError`.

Since #7 parallelized `_scan()` (bounded `ThreadPoolExecutor`, `BOX_SCAN_CONCURRENCY` default 8, clamped 1..32), a 429 during a scan is caught per-folder and counted in `fetch_errors` — i.e. that folder's collaborators/l

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/11) · 2026-07-11 · closed · 0 comments

### perf: parallelize per-folder collaboration lookups in _scan() to reduce capped coverage loss

## Problem
`_scan()` (shared by `external_collaborators`, `top_external_sharers`, and `daily_brief`) walks folders breadth-first and issues **one `get_folder_collaborations` call per folder, sequentially**. On enterprises with many top-level folders, the walk cannot finish within a typical tool-call timeout, so the scan returns `capped=true` well before covering all folders the co-admin can see.

Coverage is then a lower bound. This is honestly disclosed via `capped`, but it limits the audit's u

[Read the thread](https://github.com/shigechika/boxadm-mcp/issues/7) · 2026-07-09 · closed · 0 comments

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/shigechika/boxadm-mcp/issues).