Skip to main content
Glama
shigechika

boxadm-mcp

by shigechika

external_access_events

Surface external file accesses from enterprise admin logs, flagging downloads and previews by users outside your organization to identify potential data leakage.

Instructions

Surface external file access (DOWNLOAD / PREVIEW) from enterprise admin_logs.

Enterprise-wide (events stream): over the window, flags each access whose actor (created_by.login) is outside the org domain allowlist — an external party, or an anonymous open-link visitor (no login) — and whether it came via a shared link. Aggregates to the top externally-accessed files and the top external accessors, so an admin can spot unusual outbound data pulls.

Args: since_hours: Look-back window in hours (default 24). max_events: Cap on DOWNLOAD/PREVIEW events scanned (default 5000); the result's capped flag is true when more existed (never silently truncated). top: How many top files / accessors to return (default 20). created_by_logins: Comma-separated accessor logins to trace (empty = all). When set, switches to DLP-tracing mode (see below).

Returns window_hours, events_scanned, capped, external_access_count, via_shared_link, top_external_accessors (login + count + bytes), and top_externally_accessed_files (item id/name/ owner + external-access count). On failure returns {"error": ...} (incl. needs-login for an expired OAuth session).

Notes:

  • via_shared_link counts ALL scanned accesses that went through a shared link (internal and external), not just external ones.

  • Events are scanned oldest-first from the window start. When capped is true the aggregates reflect only the scanned (earliest) slice, NOT the full window — raise max_events for a complete picture.

  • DLP tracing (created_by_logins set): scans up to the wider of max_events and 50000 events (the accessor may sit anywhere in the window) but keeps only that accessor's events, so the answer to "which files did this account pull" is exact and bounded. The result reports events_matched (not events_scanned — this mode doesn't track the scanned total; judge coverage by capped), filtered_logins and matched_events (per access: item id/name, owner, size bytes+GB, created_at, event_type, accessor, via_shared_link); the aggregate is scoped to the filtered accessor(s). capped true means the window was not fully scanned (raise max_events).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
max_eventsNo
since_hoursNo
created_by_loginsNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behaviors: scan window and capping, via_shared_link counting details, oldest-first scanning, DLP mode behavior changes, and error handling (needs-login). This is comprehensive and goes beyond basic annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose but well-structured with sections (Args, Returns, Notes). It is front-loaded with the main purpose. Some redundancy exists (e.g., DLP mode repeated), but the complexity justifies the length. Minor conciseness improvements possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple modes, 4 parameters, no output schema), the description is exceptionally complete. It details all return fields, error conditions, and behavioral nuances like capped flag and DLP mode changes. No gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates fully by explaining each parameter: since_hours (look-back window), max_events (cap with capped flag), top (number of results), created_by_logins (DLP mode). This adds significant meaning beyond the schema's type and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Surface external file access (DOWNLOAD / PREVIEW) from enterprise admin_logs.' It specifies the verb 'surface' and resource 'external file access', distinguishing it from siblings like 'external_collaborators' and 'top_external_sharers' by focusing on admin log events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for use: 'so an admin can spot unusual outbound data pulls.' It explains normal mode and DLP tracing mode, but does not explicitly state when not to use this tool or mention alternative tools, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shigechika/boxadm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server