Loading ToolBench
Lightweight native sandboxing on Linux using kernel primitives. Provides REST API and MCP server for creating and managing isolated Linux sandboxes with resource limits, network isolation, and skill/MCP support.
HiveBox defines 10 tools via HTTP REST API handlers with reasonable naming (verb_noun pattern) and structured schemas. However, critical gaps exist: parameter descriptions are minimal or missing, output schemas are undocumented, error handling guidance is absent, and several tools lack proper input validation documentation. The tool set is reasonably composed (one clear action per tool), but descriptions are too brief to guide LLM selection reliably. Average tool definition quality is fair but below production baseline.
POST /api/v1/hiveboxes — Create a new sandbox with specified resource limits, network mode, and optional skills/MCPs
DELETE /api/v1/hiveboxes/:id — Destroy and remove a sandbox
GET /api/v1/hiveboxes/:id/files — Download a file from a sandbox
POST /api/v1/hiveboxes/:id/exec — Execute a command in an existing sandbox and return output
GET /api/v1/analytics — Get metrics history for all sandboxes or filter by sandbox ID and metric type
GET /api/v1/hiveboxes/:id — Get detailed status and configuration of a specific sandbox
Output schemas completely undocumented. Tool descriptions state HTTP endpoints but do not describe return field structure, types, or meaning. LLMs cannot infer what fields to expect in responses from create_sandbox, list_sandboxes, get_sandbox, exec_in_sandbox, etc.
Parameter descriptions are minimal or missing context. 'command' in exec_in_sandbox has no description of what shell/interpreter is used, working directory, environment variables, or output format (stdout/stderr/combined). 'network_mode' in create_sandbox lists examples but does not define semantics of 'isolated' vs 'host' vs 'bridge'.
No error handling guidance. Tools return HTTP status codes without describing what the LLM should do on failure. E.g., destroy_sandbox might fail if sandbox is in use, but no recovery path is documented. No distinction between retryable (transient network error) vs user-fixable (invalid ID) vs fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
GET /healthz — Health check endpoint for the daemon
GET /api/v1/hiveboxes/:id/files/list — List files and directories in a sandbox path
GET /api/v1/hiveboxes — List all active sandboxes with status, resource usage, and metadata
PUT /api/v1/hiveboxes/:id/files — Upload a file to a sandbox at specified path
Dangerous operations lack confirmation/dry-run support. destroy_sandbox permanently deletes a sandbox, but no confirm_before_execute or dry_run parameter exists to prevent accidental destruction. An LLM error could trigger unrecoverable data loss.
Missing pagination documentation. list_sandboxes and list_files accept no limit or offset parameters visible in the schema, yet the descriptions mention 'listing', unclear if results are capped or if 1000+ sandboxes would be returned unpaginated, blowing context window.
Credentials passed as parameters: create_sandbox accepts 'llm_api_key' as a tool parameter. API keys must never be tool parameters, they will be logged in agent traces and prompt history. Use server-side secret injection via environment variables or a vault.
Parameter 'id' is overloaded across multiple tools but has minimal description. In get_sandbox, destroy_sandbox, exec_in_sandbox, upload_file, download_file, list_files, 'id' could be a UUID, a name, an index. Descriptions should clarify 'Sandbox ID (UUID v4 returned by create_sandbox)' to enable correct tool chaining.
Tool descriptions omit context on when to use each one. list_sandboxes vs get_sandbox, when should an LLM call list_sandboxes first? What does list_sandboxes return that get_sandbox doesn't? No guidance forces the LLM to guess and potentially call both.
Enum constraints not declared. 'network_mode' in create_sandbox states 'e.g. isolated, host, bridge', this should be an enum constraint, not an example in description text. LLMs will invent modes like 'nat' or 'vlan' if not constrained.
healthz tool has no real purpose and minimal documentation. A generic health check is not an agentic tool, it serves infrastructure monitoring, not user intent. Should be removed or documented as a utility endpoint outside the tool set.