boxadm-mcp

by shigechika

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

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

Latest release: v0.9.1
Disambiguation5/5
Each tool targets a distinct aspect: health_check for server status, recent_admin_events for raw event logs, external_access_events for aggregated external access, external_collaborators for current external collaborators, public_shared_links for open shared links, top_external_sharers for ranking owners, get_user for a single user lookup, daily_brief as a combined summary, and list_folder_items for folder contents. No two tools overlap in purpose.
Naming Consistency3/5
All names use snake_case and are descriptive, but there's a mix of verb-first (health_check, get_user, list_folder_items) and noun/adjective-first (recent_admin_events, external_collaborators, daily_brief) patterns. This inconsistency makes the naming convention less predictable than a uniform verb_noun style.
Tool Count5/5
The 9 tools are well-suited to the server's purpose of Box admin monitoring and external access analysis. Neither too few to be thin nor too many to be unwieldy, each tool has a clear role.
Completeness4/5
The surface covers the full lifecycle of external access monitoring: raw event access, aggregated access analysis, current external collaboration state, open shared link enumeration, ranking by exposure, individual user lookup, folder listing, and a combined daily brief. Minor gaps exist, such as no tool to modify permissions or list all users, but these are likely outside the server's read-only monitoring scope.
Average 4.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 61 commits in the last 12 weeks
- Last stable release on August 20, 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?
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?
The description discloses extensive behavior: it refuses invalid root_folder_id with an error, skips externally-owned folders with separate reporting, and explains the max_folders cap via the `capped` field. Error handling for fetch errors is also detailed, covering persistent API errors and retries—all beyond what any annotation could provide.
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?
The description is front-loaded with a one-sentence summary, followed by structured details organized into coherent paragraphs. Each sentence contributes new information, such as coverage limitations and return fields, justifying its length.
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?
For a tool with no output schema and no annotations, the description provides a thorough account of return values, error behavior, and limitations (e.g., coverage only reflects co-admin's accessible folders). It covers all critical aspects an agent needs to invoke and interpret results correctly.
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?
Despite 0% schema description coverage, the Args section richly explains each parameter: root_folder_id's format and validation, max_folders' default and `capped` disclosure, and max_depth's recursion semantics. This fully compensates for the sparse 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 first line 'List external collaborators on Box folders (current state, enumeration)' uses a specific verb and resource, clearly distinguishing the tool's purpose. Though siblings like external_access_events exist, the description unambiguously defines what this tool does.
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?
Clear context is provided about walking folders from the root 'All Files' and the tool's usefulness for reviewing external standing access. However, no explicit alternatives or when-not-to-use conditions are given, aside from the out-of-scope externally-owned folders, which is more about tool behavior than usage 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 provided, the description carries the full burden and does so excellently. It discloses traversal behavior, access limitations, caps, error handling for invalid root_folder_id, fetch_errors count, and exact conditions under which coverage is complete. This far exceeds minimal expectations.
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?
The description is well-structured with an opening summary, per-argument explanations, and a coverage/output note. Despite its length, every sentence adds necessary operational or behavioral detail, and the formatting aids readability.
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 and a moderately complex traversal tool, the description is complete. It enumerates all returned fields, explains their semantics, covers failure modes, and specifies scope boundaries. An agent has enough information to predict behavior and handle edge cases.
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%, so the description must fully compensate. It explains all three parameters in depth: root_folder_id format and validation failure behavior, max_folders default and truncation disclosure, and max_depth default with recursion guidance. This adds significant meaning beyond the raw 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 opens with a specific verb and resource: "List items with an open ('anyone with the link') shared link." It clearly defines the tool's scope (enumeration of open shared links) and differentiates it from sibling tools focused on events, collaborators, or sharers.
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 usage context: it walks folders the authenticating co-admin user can see, starts from a specified root folder, and enumerates only open shared links. It does not explicitly name alternatives or state when not to use this tool, but the context is precise enough for an agent to decide.
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?
There are no annotations, so the description carries the full transparency burden. It discloses exact and case-insensitive matching, the prefix-search pitfall that can return other users, the meaning of absent enterprise, non-active status, is_platform_access_only, truncated search results, and the deliberate absence of a 'found' field on error.
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 front-loaded with the core action, and each major behavioral point has its own section. However, it is quite long for a one-parameter tool and repeats the prefix-search/filtering caveat in multiple places, so a little trimming would earn the top score.
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?
With no output schema and no annotations, the description must be the complete contract, and it is. It fully documents the success shape, the error shape, auth caveats, return field meanings, and the distinction between 'not found' and 'lookup failed'.
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?
The schema gives only a type and title, so this description is the complete semantic source. It fully explains the 'login' parameter: full email address, not display name or user id, exact case-insensitive match, and how a partial login will not match.
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 opens with a specific operation: 'Look up ONE Box account by its exact login.' It directly distinguishes itself from siblings by stating that every other tool reads the event stream or walks folders, while this tool is the only one that answers directly about an account.
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?
It explicitly states when to use the tool: 'Use it when a specific account is named.' It also tells the agent what the tool cannot do — list, search, or enumerate accounts — and advises consulting the identity provider when a duplicate or alias login is suspected.
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 provided, the description fully discloses behavior: it does not read file content or create shared links, explains case-insensitive matching, details truncation flags (capped, returned < matched), and specifies the failure shape where count keys are absent, ensuring a failed listing cannot be misread as empty.
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 clear sections (overview, use case, arguments, return details) but is somewhat verbose, repeating certain points like 'newest first' and the explanation of uploaded_by behavior. Despite slight redundancy, it remains focused and front-loaded with the essence.
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?
The description is complete given the tool's complexity: it covers the input parameters in depth, spells out the return shape (folder_id, items, returned/matched, total_in_folder, capped, note), and explains error handling. No output schema exists, so the description fully compensates.
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?
The description adds extensive meaning beyond the schema, which only provides types and defaults. Each parameter is explained: folder_id format including '0' as root, uploaded_by exact matching case-insensitively, since/until date handling with UTC offset requirement, and limit only affecting return count not search scope. This goes far beyond the schema's raw attributes.
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 states exactly what the tool does: 'List ONE Box folder's contents, newest first, with who uploaded each item.' It uses a specific verb (list) and resource (Box folder), and distinguishes itself from sibling tools like health_check and external_access_events by focusing on folder contents.
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?
The description explicitly frames when to use the tool: 'Written for a help desk answering a submitted enquiry whose attachments land in a Box folder.' It also differentiates from 'enumeration tools' by noting the same convention for folder IDs, giving clear contextual 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

boxadm-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![boxadm-mcp MCP server – quality and maintenance score on Glama](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 – quality and maintenance score on Glama](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