boxadm-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation5/5
Each tool targets a distinct aspect of Box DLP: daily_brief provides a summary, external_access_events focuses on event logs, external_collaborators on collaborations, public_shared_links on open links, top_external_sharers on owner rankings, recent_admin_events on raw logs, and health_check on server status. No overlap or confusion.
Naming Consistency5/5
All tool names use consistent snake_case with descriptive verb-noun structure (e.g., external_access_events, top_external_sharers). The naming pattern is uniform and predictable.
Tool Count5/5
With 7 tools, the server is well-scoped for a Box administration and DLP monitoring domain. Each tool covers a clear function, and the count aligns with typical MCP server sizes without being excessive or insufficient.
Completeness4/5
The tool set covers essential monitoring and enumeration needs: health check, raw events, external access, collaborations, open links, and owner exposure. Minor gaps exist, such as missing write operations or detailed file-level drills, but the surface is largely complete for read-oriented DLP tasks.
Average 4.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 47 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: it reuses a cached folder scan, returns an error object on failure, mentions coverage/caps caveats (capped flags, enumeration limited to co-admin visible content), and explains default behavior (top defaults to 5 for compact summary).
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 well-structured with bullet points and clear sections, and the main purpose is front-loaded. It is slightly lengthy but each part adds value (purpose, behavioral notes, caveats).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return format. It mentions an error object on failure but does not describe the success response structure (e.g., fields, format of 'access' and 'exposure' data). This is a notable gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'since_hours' (last N hours) and 'top' (defaults to 5 for compact summary) but only vaguely states 'Args mirror the underlying tools' for other parameters like max_depth, max_events, max_folders, lacking individual explanations.
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 provides a combined brief of external access events and external-sharing state (enumeration). It distinguishes from siblings like external_access_events and external_collaborators by explicitly saying it combines two underlying tools into one call.
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 on when to use it (e.g., morning DLP brief, reuses cached folder scan alongside other enumeration tools). However, it does not explicitly state when not to use it or mention alternative tools by name, only implying they are the individual underlying tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that coverage is limited to the co-admin user's visible content and caps, and that fetch errors indicate incomplete coverage. However, it does not explicitly state that the tool is read-only, though the context implies no side effects.
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 well-structured and covers purpose, usage, parameters, coverage limitations, and return format in a logical flow. It is slightly verbose but every sentence adds value, and it remains clear.
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 no output schema, the description thoroughly explains the return structure (folders_scanned, capped, fetch_errors, top_external_sharers) and error handling. Parameters are fully explained, and limitations are clearly stated. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema (which has 0% coverage) by explaining all four parameters: root_folder_id, max_folders, max_depth as traversal bounds (referencing external_collaborators), and top as the number of owners. The explanation is adequate, though it relies on knowledge of another tool for full parameter details.
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 the tool ranks internal owners by external exposure, using a traversal method similar to sibling tools. The verb 'rank' and resource 'internal owners by external exposure' are specific, and it distinguishes itself by focusing on owners rather than just listing collaborators or links.
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 explains the tool is built on the same traversal as external_collaborators/public_shared_links, implying use when you need aggregated exposure per owner. However, it does not explicitly state when not to use it (e.g., if only raw lists are needed) or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral traits such as skipping externally-owned folders, reporting them separately, coverage limits (capped, fetch_errors), and the return values on success and failure.
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 detailed and well-structured with sections, but slightly verbose. It front-loads the main purpose and uses Args list. Every sentence adds value; could be tightened but overall effective.
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 complexity of the tool and absence of output schema, the description covers all necessary aspects: behavior, return fields, error handling, limitations, and edge cases (externally-owned folders). It is self-contained and complete.
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 description coverage is 0%, but description fully explains each parameter (root_folder_id, max_folders, max_depth) with defaults and semantics, including the meaning of 'capped' in output. Adds significant value beyond the schema.
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 'List external collaborators on Box folders' and specifies it's a current state enumeration. It distinguishes itself from siblings by focusing on standing access rather than events or other metrics.
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?
Provides explicit context on when to use (review who outside the org has access) and what is out of scope (externally-owned folders). Mentions limitations (co-admin user scope, caps) but does not explicitly name alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it makes one token request, probes events, and returns standardized keys. It also explains degraded/error states and auth_mode fallback, ensuring the agent knows exactly what to expect.
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 well-structured with an initial summary, usage guidance, and detailed return keys. It is slightly lengthy but every sentence is informative; could be slightly more concise but remains clear.
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 simplicity of the tool and lack of output schema, the description is complete: covers purpose, when to use, behavior, and all return keys. No gaps remain.
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?
There are no parameters, so schema coverage is 100% trivially. The description adds all meaning by detailing the return structure and behavior, fully compensating for the empty schema.
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 the tool reports server version, connectivity/auth, and configuration. It distinguishes itself from sibling tools that focus on admin events, external access, etc., by being a health check for the server itself.
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?
Explicitly advises 'Call this at session start (or after a tool-call timeout)' and notes it is lightweight with one token request and a single-row events probe. Does not provide explicit when-not or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses walking behavior, caps, truncation disclosure, fetch_errors, return fields, and error format. It explains coverage completeness conditions. This is highly transparent.
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 well-structured with a title line, parameter explanations, coverage note, and return format. It is slightly lengthy but every sentence is informative. Front-loaded with purpose. A bit more conciseness could be achieved, but it is efficient.
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 has 3 parameters, no output schema, and no annotations, the description covers all aspects: purpose, parameters, return values, limitations, and error handling. It explains when coverage is complete. The agent can fully understand how to invoke and interpret results.
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 description coverage is 0% (no param descriptions in schema). The description adds full meaning: explains root_folder_id as starting folder with default '0', max_folders cap with capped flag, max_depth recursion. This compensates entirely for the lack of schema descriptions.
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 the tool enumerates items with open shared links. It specifies the resource (items with 'anyone with the link' access) and uses a specific verb ('List'). It distinguishes from sibling tools like 'external_collaborators' or 'top_external_sharers' by focusing on public shared links.
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 context (walks folders the co-admin can see, reports high-exposure mode) and limitations (caps, fetch_errors). It implies usage for finding open shared links but does not explicitly state when to use this versus alternatives or when not to use it. The clarity is high but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns raw Box events verbatim, Box caps a single page at 500, manual paging is needed, and lists typical event types for external-sharing work. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: a one-line summary followed by a paragraph explaining its diagnostic purpose, then a clear bullet-style args list, and a note on paging with sibling reference. No superfluous text; every sentence adds value.
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 no output schema, the description explains that results are raw events verbatim and gives examples of relevant event types. It also covers pagination limitations and directs to a sibling for automatic paging. Complete for a diagnostic tool of this complexity.
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?
Though schema description coverage is 0%, the description provides detailed explanations for all 4 parameters: 'event_types' as comma-separated filter, 'since_hours' as look-back window, 'limit' as max events per page, and 'stream_position' for pagination. This fully compensates for the lack of schema descriptions.
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 fetches recent enterprise admin_logs events as a raw passthrough. It distinguishes itself from sibling tools like 'external_access_events' by noting that this tool requires manual paging, while the sibling pages automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself as a diagnostic/starter tool to confirm event types and field shapes before using analytics tools. Specifically mentions when to prefer 'external_access_events' for automatic paging, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![boxadm-mcp MCP server](https://glama.ai/mcp/servers/shigechika/boxadm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shigechika/boxadm-mcp)

Score Badge

Copy to your README.md:

[![boxadm-mcp MCP server](https://glama.ai/mcp/servers/shigechika/boxadm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shigechika/boxadm-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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