mcp-box

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: lifecycle (create/list/get/resume/stop/fork), execution (exec/exec_background/job_status/interrupt), file access (read/write/download), and desktop. The overlap between exec and exec_background is clear from their descriptions—one is synchronous with a timeout, the other is asynchronous via nohup.
Naming Consistency5/5
All tools share the 'box_' prefix and use lowercase verbs or verb_noun patterns (e.g., box_create, box_read_file, box_stop_and_wait). The naming is uniformly descriptive and follows a recognizable convention throughout.
Tool Count5/5
14 tools is well-scoped for a cloud computer management server, covering lifecycle, command execution, job handling, file operations, and desktop access without being excessive. Each tool serves a distinct purpose and earns its place.
Completeness4/5
The surface covers the major workflows: box lifecycle (create, get, list, resume, stop, fork), command execution (foreground, background, interrupt, job status), and file operations (read, write, download). Minor gaps exist, such as no explicit delete/destroy tool and no direct retrieval of background job stdout/stderr, but agents can work around these with existing tools.
Average 3.7/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks this as non-read-only (readOnlyHint=false) and open-world (openWorldHint=true). The description adds a precondition that the box must be 'ready' and mentions the timeout cap (though redundant with the schema's maximum). It does not disclose potential side effects of running arbitrary shell commands, such as modifying files or network access, beyond what annotations imply.
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 very short with the main action front-loaded. The second sentence about timeoutSeconds duplicates the schema's maximum, so it's slightly redundant, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a shell command execution tool with no output schema, the description is incomplete. It does not explain return values, stdout/stderr handling, exit codes, or how results are retrieved. It also does not mention the synchronous nature or relationship to box_exec_background. The 'ready box' precondition is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%; three of four parameters have descriptions. The description adds no new parameter semantics; the only parameter mention ('timeoutSeconds is capped at 60') simply restates the schema's maximum constraint. No explanation of cwd or boxId beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and names the resource ('a shell command in a ready box'), making the core purpose clear. However, it does not differentiate from the sibling tool box_exec_background, which likely also runs shell commands but asynchronously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like box_exec_background. It only notes a timeout cap, which is a constraint, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is established. The description adds minimal context ('for the account') but does not disclose pagination, rate limits, or other behavioral traits beyond the annotations.
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 a single concise sentence with no redundant words. It front-loads the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with three optional parameters and no output schema. It does not explain what boxes represent, how pagination works, or what the response contains, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the limit, state, or cursor parameters. With only 33% schema coverage, the description fails to compensate, leaving the agent without guidance on how to use these parameters.
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 action (List) and resource (boxes) with a scope ('for the account'). It differentiates from siblings like box_create and box_get by indicating it enumerates existing boxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without any context on selection criteria or exclusions.
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?
The description discloses that the URL is 'secret-bearing' and instructs 'Never log the full URL,' adding important behavioral context beyond the readOnlyHint and openWorldHint annotations. It does not contradict annotations.
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 extremely concise with two short sentences. The first sentence states purpose, and the second provides a critical safety instruction. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, low schema coverage, and no output schema, the description is too brief to be complete. It omits parameter explanations, return value details, and usage context, making it inadequate for full agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only boxId is described). The description mentions no parameters (vnc, publicAccess) and fails to explain their meaning or effect, leaving the agent without necessary parameter semantics.
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's purpose with a specific verb ('Get') and resource ('desktop/noVNC URL'). It distinguishes itself from siblings by specifying a URL for desktop access, which is unique among the listed box_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does and adds a logging caution, but offers no context about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description is not required to disclose that. It adds the fact that it reads from files under .mcp-box-jobs/, which is useful behavioral context. However, it does not describe expected return values, error behavior if files are missing, or whether the polling is one-shot or repeated, leaving some gaps.
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 a single concise sentence that states the action and the resource. There is no redundant or filler content; every word serves a purpose, and the key information is front-loaded.
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?
The tool is simple and read-only, but with no output schema, the description ought to clarify what the status output looks like or how to interpret it. The mention of files hints at persistence but lacks guidance on handling missing jobs or understanding state values. Adequate for basic understanding, yet leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes boxId but not jobId. The description mentions 'jobId' in the file path, giving some meaning to that parameter, but it does not elaborate on boxId or how it is used. With 50% schema coverage, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls background job state, with a specific resource (the .mcp-box-jobs/<jobId>/ files). It is distinct from sibling tools like box_exec_background or box_get due to the 'poll' action and file-path reference, though it doesn't explicitly contrast itself with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check the status of background jobs, but it offers no explicit guidance on when to use it versus siblings, nor any prerequisites or exclusions. There is no mention of alternatives or conditions that would make this tool appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: false, so the description does not contradict. However, it adds no behavioral context beyond the action itself—no mention of overwriting behavior, side effects, permissions, or return values. The openWorldHint: true is not explained, and the description fails to disclose any additional traits.
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 a single, concise sentence that front-loads the action ('Write a file') and includes necessary context ('relative to the box workdir') without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 only a one-line description, the description is incomplete. It does not explain return values, error behavior, or how the tool interacts with other box tools. The concept 'box workdir' is undefined, and the presence of sibling tools such as box_create and box_read_file is not leveraged for context.
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 only 25% (only boxId has a description). The description adds some meaning by clarifying that path is 'relative to the box workdir', which helps agents understand path semantics. However, content and encoding are left without added context, and it does not fully compensate for the low schema coverage.
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 'Write a file relative to the box workdir' with a specific verb (Write) and resource (file), and the mention of 'box workdir' clearly distinguishes it from sibling tools like box_read_file or box_exec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (write a file to the box workdir) but provides no explicit when-to-use guidance, exclusions, or alternatives. It relies on the agent to infer when this tool is appropriate, which is acceptable but not explicit.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds a valuable behavioral detail that desktop URLs are redacted in the summary field, which is not captured in annotations.
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 only two sentences, front-loaded with the primary action, and every sentence earns its place. The redaction note is concise and informative without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with good annotations, the description is adequately complete. It explains the core function and a notable behavior (URL redaction). However, it does not describe the shape of the returned state or any potential error conditions, which would be useful but not essential given the simplicity.
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?
The schema already documents the single parameter 'boxId' with description 'Box id (bx_…)' at 100% coverage. The description adds no further parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with resource 'box state', making its function immediately clear. It distinguishes from sibling tools like box_list and box_read_file by focusing on state retrieval, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or contexts where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds the workdir-relative scope. However, it does not disclose behavior such as error handling, encoding defaults, or what happens if the file/path is invalid. No contradiction with annotations.
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?
A single, front-loaded sentence with no wasted words. It states the action and the key scoping detail immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with good annotations, this is mostly complete. The main gap is that no output schema exists and the description does not state what is returned, but the core behavior is clear.
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?
The description adds meaning by clarifying that the 'path' is relative to the box workdir. However, schema coverage is only 33%, and the description does not explain the 'encoding' parameter or the default behavior, so it only partially compensates.
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 uses a specific verb ('Read') and resource ('a file'), and adds the scope 'relative to the box workdir.' This clearly distinguishes it from sibling tools like box_write_file and box_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (reading file contents within a box workdir) but does not explicitly state when to use it over alternatives, nor does it mention exclusions or prerequisites. Sibling differentiation is only implicit through naming.
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?
The description adds behavioral details beyond the annotations, specifically that isolated mode ignores env and that the tool waits until the box is ready when possible. These are non-obvious behaviors not covered by readOnlyHint, openWorldHint, or destructiveHint, providing meaningful context.
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 three short sentences, front-loaded with the main purpose in the first sentence. It is concise with no redundant or wasted words.
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?
The tool has no output schema and descriptions for all params, but the description does not explain what happens after creation (e.g., return value, how to interact with the created box). It mentions waiting until ready but not what is returned or failure behavior. However, given the simple create action and annotations, the description is adequate but not fully complete.
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?
The input schema covers all four parameters with 100% description coverage. The description adds marginal value by clarifying that env is always noEnv in isolated mode, reinforcing the schema's note that env is trusted mode only. No additional parameter semantics are provided for name, type, or ttlSeconds.
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's purpose: 'Create a Box cloud computer.' It uses a specific verb and resource, and it is unambiguous. The purpose is distinct from sibling tools like box_list or box_resume, which operate on existing boxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some contextual hints, such as 'Isolated mode always uses noEnv' and 'Waits until ready when possible,' but it does not explicitly state when to use this tool versus alternatives like box_resume or box_list. It implies usage for creating new boxes but lacks explicit exclusions or alternative guidance.
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?
Annotations already indicate this is a write operation (readOnlyHint=false), so the description adds value by specifying the fork source ('latest snapshot') and the behavioral note that 'isolated forks always use noEnv'. This goes beyond the annotations but could be more explicit about side effects or return behavior.
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 two sentences with no redundant words. The first sentence is front-loaded with the purpose, and the second adds a useful caveat. It earns its keep with minimal length.
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?
The description is sufficient for basic invocation with the documented parameters, but lacks any mention of return values, errors, or what the fork operation produces. Given the lack of an output schema and the potential ambiguity of 'isolated forks', the description feels moderately complete but not fully self-sufficient.
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?
Schema description coverage is 100% for the two parameters (boxId, env). The description adds extra context ('isolated forks always use noEnv') that is not present in the schema, clarifying the behavior of the env parameter and the isolated fork scenario.
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 a specific action ('fork a box') and its source ('from its latest snapshot'). This distinguishes it from sibling tools like box_create (new box) and box_resume (resume existing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description does not mention alternatives or any prerequisite/exclusion conditions, leaving the agent to infer usage from the tool name alone.
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?
The annotations already signal readOnlyHint=false and openWorldHint=true, and the description adds meaningful context: it runs via nohup, under a specific job directory, and returns immediately. This goes beyond the annotations, though it does not elaborate on how to monitor or clean up the job, which would have made it richer.
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 a single, front-loaded sentence of about 11 words that clearly conveys the action, method, and immediate return. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with two simple parameters and no output schema, covering the core contract: what it does, how (nohup under job dir), and that it returns immediately. It does not mention how to check job status or that sibling tools exist for that, but this is not critical for using the tool correctly.
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 coverage is 100% with both parameters described adequately ('Box id (bx_…)' and 'Shell command to run in background'). The description adds the 'nohup' and job-directory context, but these are more behavioral than parameter-specific, so it does not substantially enhance parameter understanding.
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 uses the specific verb 'Start' and names the resource ('long command via nohup under .mcp-box-jobs/<jobId>/') and clearly states it returns immediately. This distinguishes it from synchronous execution tools like box_exec and from status-checking tools like box_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for long-running commands by mentioning 'long command' and 'return immediately', but it does not explicitly state when to prefer this over alternatives or provide exclusions. There is no mention of sibling tools or a clear 'use this when' directive.
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?
Annotations already declare readOnlyHint=true, so the description adds value by disclosing the base64 return format and the ~2MB size cap. It doesn't describe error handling for oversized files, but this is a useful behavioral detail beyond annotations.
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?
Two sentences, front-loaded with the core action and format, followed by a concise usage guideline. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with no output schema, the description covers the key behavioral contract (base64, size limit) and gives usage direction. The main gap is the undocumented 'path' parameter, but overall the description is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents boxId, while path has no description and the tool description doesn't explain 'path' either. With schema coverage at 50%, the description fails to compensate for the undocumented 'path' parameter, leaving the agent to infer its meaning.
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 a specific action ('Download an artifact'), the return format (base64), and a size constraint (~2MB). This clearly distinguishes it from sibling tools like box_get or box_read_file by specifying the encoding and size limitation.
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 explicitly advises 'Prefer box-side tools for larger files,' providing a clear when-not-to-use condition and pointing to an alternative class of tools. It doesn't name specific sibling tools, but the guidance is actionable.
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?
Annotations only state readOnlyHint false and openWorldHint true. The description adds valuable context beyond annotations: 'best-effort' signals the operation may not be guaranteed, and 'prompt work' clarifies the exact scope of what is interrupted. This transparency is useful for an agent deciding to invoke it.
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 a single, front-loaded sentence with zero waste. It immediately states the action and includes a parenthetical that clarifies a key distinction, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core behavioral context (best-effort, interrupt, prompt work). It could be more complete by explaining what happens after an interrupt or how it relates to box_resume, but the current description is sufficient for basic invocation.
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?
The input schema fully describes the single parameter (boxId) with a description ('Box id (bx_…)'), covering 100% of schema descriptions. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
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 uses a specific verb ('interrupt') and resource ('prompt work on a box'), clearly stating what the tool does. It also distinguishes itself by explicitly excluding 'shell background jobs', setting it apart from sibling tools like box_exec_background and box_job_status.
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 when to use the tool (interrupting prompt work) and implicitly when not to (shell background jobs). However, it does not explicitly name alternatives or elaborate on scenarios involving sibling tools like box_stop_and_wait, so it falls short of full guidance.
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?
Beyond annotations (readOnlyHint=false, openWorldHint=true), the description adds 'wait until ready', disclosing blocking behavior. It does not contradict annotations and provides useful context about execution semantics.
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?
Single sentence, front-loaded with the action, and no superfluous words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with no output schema and open-world annotations, the description covers the core function and blocking behavior. It could mention potential timeouts or error conditions, but these are not essential for basic usage.
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?
The input schema already documents boxId as a required string with format 'bx_…', so the description adds no additional parameter meaning. With 100% schema coverage, the baseline of 3 is appropriate.
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 identifies the action (resume) and target (an archived box), plus the outcome (wait until ready). The specific verb 'resume' distinguishes it from sibling tools like box_stop_and_wait and box_fork.
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 implies use when a box is archived and needs to be active again. It provides clear context but does not explicitly name alternatives or when-not scenarios, though the self-evident purpose mitigates this.
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?
The description adds behavioral context beyond the annotations: it waits until archived, requires confirmation, and force mode is restricted to trusted users. This complements the destructiveHint=true annotation without contradicting it.
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 concise and front-loaded: a clear action statement followed by key requirements. Every word adds value, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with three parameters and no output schema, the description covers the core action, prerequisites, and special conditions. It lacks details on return values or error handling, but those are not expected without an output schema.
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 coverage is 100%, so parameters are well-documented there. The description mentions confirm and force's trusted requirement, but this mostly echoes the schema descriptions without adding significant new meaning.
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 'Stop a box and wait until archived,' using a specific verb and resource. This distinguishes it from sibling tools like box_interrupt or box_resume by adding the 'wait until archived' behavior.
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 when to use this tool: stopping a box and waiting for archival. It also states prerequisites ('Requires confirm:true' and 'force requires trusted mode'), though it does not explicitly mention alternative tools or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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/EnzoTironi/mcp-box'

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