Loading ToolBench
Local MCP server that exposes your machine to AI agents via terminal tools
openlol provides 12 filesystem and system tools with complete JSON Schema definitions and non-trivial descriptions. Naming is consistently verb-forward (execute_, read_, write_, delete_, etc.), and all parameters have type declarations and descriptions. However, descriptions are sparse (most 50-150 chars, below the 194-char baseline), lack LLM-optimized context about when to use each tool vs alternatives, and do not document relationships between tools or the concept of 'scoped folder' boundary. No output schemas are documented, the response format is inferred only from the tool name. Error handling and recovery guidance are completely absent. Security considerations (path traversal, symlink attacks, permission checks) are not addressed in descriptions, despite tools having destructive capability. Tool composition works (e.g., list_directory → read_file chain), but several tools are narrow and could be consolidated.
Append content to the end of an existing file (or create it if it doesn't exist).
Create a directory (and any missing parent directories) within the scoped folder.
Delete a file or directory (recursively) within the scoped folder.
Execute a terminal/shell command in the scoped working directory. Use this for any system operation, file manipulation, or running scripts. Commands run in the folder specified when the server started.
Check whether a file or directory exists within the scoped folder.
Get disk/storage usage for all mounted drives or partitions on the machine.
No output schemas documented. Tool response structures are entirely undocumented, LLMs cannot predict what fields (file_contents, error_code, success_flag, etc.) will be returned, forcing trial-and-error parsing and downstream tool selection.
Descriptions lack LLM-optimized context. Most descriptions (50-150 chars) are bare functional statements ('Read the contents of a file') without WHEN-to-use guidance, prerequisites, or relationship to peer tools. At 194-char baseline, typical descriptions should answer: What does it do? When to call instead of alternatives? What does it return? E.g., 'read_file' does not explain it should be called after list_directory to discover what files exist, nor does it mention the scoped folder boundary.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
List environment variables available to the server process. Optionally filter by name.
Get information about the host machine: OS, architecture, memory usage, uptime, and Node version.
List the contents of a directory within the scoped folder. Shows files and subdirectories.
Move or rename a file/directory within the scoped folder.
Read the contents of a file within the scoped folder. Returns the full text content.
Create or overwrite a file with the given content. Creates parent directories automatically.
No error handling or recovery guidance. Tool descriptions do not specify what errors can occur (e.g., 'file not found', 'permission denied', 'path traversal blocked') or how LLMs should respond. A bare error response gives agents no guidance on whether to retry, fix input, or abort. No distinction between retryable and fatal errors.
Security & boundary protections undocumented. No description warns that tools operate within a 'scoped folder' boundary or how path traversal is prevented (e.g., '../' attacks). Destructive operations (delete_file, execute_command) lack dry-run or confirmation patterns. No mention of permission checks or audit logging.
Timeout parameter in execute_command is optional but max (120000ms) is not documented in constraint form. LLMs may pass unsafe values outside the range, or assume 30s is a hard limit when it is actually a default. Parameter constraints should be formally stated: 'timeout (milliseconds, 1 - 120000, default 30000)'.
get_environment_variables filter parameter lacks format constraint. LLMs do not know if 'filter' is a substring match, regex, or exact name. Should state: 'Substring filter (case-insensitive, e.g., "NODE" matches NODE_ENV, NODE_PATH).'
No tool composition guidance. Descriptions do not explain common workflows (e.g., 'First call list_directory to discover files, then read_file on a specific path'). This forces LLMs to infer composition from trial and error, increasing wasted calls.