Loading ToolBench
MCP server for full computer control - OODA loop enabled. CLI, CRUD, Filesystem, Screen capture, Input simulation, Window management, Clipboard, and System operations.
The server defines 47 tools across filesystem, CRUD, screen/input, browser, and system operations. While most tools have basic descriptions and some schema definition is visible, significant quality gaps emerge across naming clarity, parameter descriptions, output schemas, and error handling. Many tools combine multiple concerns (e.g., batch_tools is a dispatcher that can execute ANY operation), and descriptions often lack the specificity needed for LLM tool selection. The server is aimed at full computer control (OODA loop), which is inherently high-risk, yet security documentation and error guidance are minimal. Output schemas are largely inferred or undocumented. Per-tool analysis reveals consistent under-specification in parameters and output fields.
Apply multiple search/replace operations to a file in a single atomic operation. Validates all blocks before applying any changes. Use dryRun=true for preview. Use startLine hints for faster matching in large files.
Apply multiple search/replace operations to a single file sequentially. Each edit operates on the result of the previous edit. Supports partial success - completed edits are saved even if later edits fail. Use stopOnError to halt on first failure. Use dryRun for preview.
Generic dispatcher for batching ANY tool operations in parallel or sequential mode
Click at coordinates on the screen
Click an element on the page
Close the browser instance
Vague parameter descriptions: 47 tools have minimal or missing parameter descriptions. Examples: 'region' in screenshot is described only as 'Optional region to capture' without specifying format (coordinates? object fields?). 'button' in click is 'Mouse button (left, right, middle)' but no default stated. 'selector' in click_element says 'CSS or XPath selector' but doesn't clarify which is preferred or how the tool disambiguates.
Output schemas not documented: No tool shows its response format. Examples: read_file returns what? A string? Object with { content, size, lines }? search_files returns what structure? get_page_content with format='markdown' vs 'html', what fields are in the response? Without documented output schemas, LLMs cannot plan downstream operations or extract required fields (e.g., IDs for tool chaining).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Copy a file or directory. For multiple operations, use batch_tools with copy_file operations.
Create a directory. Creates parent directories as needed.
Create a new record in a CRUD collection
Delete a record from a CRUD collection
Read records from a CRUD collection
Update a record in a CRUD collection
Delete a file or directory. For multiple deletions, use batch_tools with delete_file operations.
Search and replace text in a file with fuzzy matching fallback. Shows diff preview when exact match fails. Use expectedReplacements to control how many occurrences to replace. Use dryRun=true for preview only.
Evaluate JavaScript in the browser context
Execute shell commands on the host system (YOLO mode)
Execute code in memory without saving to file. Supports python, node, r, powershell, bash.
Get file/directory metadata (size, dates, type). For multiple paths, use batch_tools with file_info operations.
Focus a window by title
Read text from clipboard
Get current configuration
Get console logs from the browser
Generate a diff preview showing what changes would be made without applying them. Supports unified, inline (character-level), and side-by-side formats.
Get content from the current page
Extract text from the screen using OCR
Get system information
Get information about open windows
Press a key or key combination
Launch a browser instance
List contents of a directory
Move/rename a file or directory. For multiple operations, use batch_tools with move_file operations.
Navigate to a URL in the browser
Read file contents. ⚠️ CONTEXT WARNING: Truncates at 500 lines. For large files or targeted access, PREFER these surgical alternatives: • read_file_lines - Read specific line ranges (use offset: -50 for last 50 lines) • search_in_file - Find patterns with context lines • edit_block - Search/replace without full read Full file reads consume context rapidly. Be surgical.
Read specific lines from a file (token-efficient). Returns line range with optional line numbers. Use this instead of read_file when you only need a portion of a large file.
Reset configuration to defaults
Take a screenshot of the screen
Take a screenshot of the current page
Search for files by glob pattern in a directory tree. Patterns containing "/" match paths relative to the search root (for example, "**/*.ts" or "src/tools/*.ts"); patterns without a separator match file basenames (for example, "*.ts"). Supports **, *, ?, and {a,b} alternation; matching is case-insensitive.
Search for text or regex patterns within a file. Returns matching lines with optional context. More efficient than reading entire file when looking for specific content.
Write text to clipboard
Set a specific configuration value
Replace a unique string in a file with another string. Handles CRLF/LF line-ending mismatches automatically (search text uses file's convention). The string to replace must appear exactly once. For fuzzy matching or partial matches, use edit_block instead; for multi-block edits on one file, use apply_diff.
Poll a growing file for new content, OR block waiting for new content up to a timeout. Byte-offset cursor lets you resume cleanly across multiple calls. Use fromByte=<previous endByte> to resume streaming. Use timeoutSeconds>0 to block until new content appears (good for watching logs while telling the user to interact with an app). Detects file rotation via size shrink. Prefer this over exec_cli with Get-Content -Wait.
Type text on the keyboard
Type text into a page element
Write content to a file
Write or append content starting from a specific line number. Useful for partial file updates without reading the entire file. Use insertBefore=true to insert before the line.
batch_tools is too generic: The tool name 'batch_tools' combined with 'Generic dispatcher for batching ANY tool operations' violates the single-responsibility principle. LLMs cannot infer from the name what it does. Worse, the tool accepts arbitrary 'tool' names and 'args' as free-form objects, no validation that the nested tool exists or that args match its schema. This is a security risk (LLMs could invoke tools that should not be available) and a usability liability (no discovery of valid nested operations).
No confirmation step for destructive operations: delete_file, crud_delete, reset_config, and execute_code are irreversible but have no dry-run, confirmation, or review step. Agents are prone to mistakes, a delete_file() call with a typo in the path will silently destroy data. No error guidance either, if deletion fails due to permissions, the LLM gets no hint to ask the user for elevation.
Insufficient error handling and recovery guidance: No tool shows error responses or recovery hints. Example: If read_file fails because the file doesn't exist, what does the LLM see? If click fails because the element is not found, should the agent retry, take a screenshot, or ask the user? If execute_code times out, is it retryable? Without categorized errors and recovery guidance, agents make poor decisions when tools fail.
CRUD tools use generic 'id' and 'data' parameters: crud_create, crud_read, crud_update, crud_delete all take 'id' and 'data' as generic strings/objects. What is the structure of 'data'? Are there required fields? What type constraints? The 'id' parameter has no description beyond the label. For a collection like 'users', does the id expect a UUID, email, or auto-incremented integer? Without specifics, LLMs will guess and fail.
Screen/input tools lack coordinate or region specifications: click, screenshot, get_screen_text all mention 'region' (optional object) without documenting the object structure. Is it { x, y, width, height }? { top, left, bottom, right }? Pixel or percentage coordinates? Baseline undefined, agents will pass malformed regions and fail.
Browser tool descriptions are vague about state management: launch_browser, close_browser, navigate_page, etc. do not clarify: Is there a global browser instance, or can agents launch multiple? If an agent calls launch_browser twice, does the second call fail or replace the first? If navigate_page is called before launch_browser, what happens? No state-management clarity forces agents to over-call or guess control flow.
No pagination or result limits documented: search_files, crud_read, get_window_info, none state how many results are returned or if pagination is supported. If a directory has 10,000 files and the LLM calls search_files, does the tool return all 10,000 (blowing the context window) or cap at a default limit? No limit stated, behavior is undefined.
execute_code and exec_cli support multiple languages/shells but no validation: execute_code lists 'python, node, r, powershell, bash', what if the LLM passes 'javascript' or 'perl'? Does the tool error clearly, or fail silently? No enum constraint, no validation hint. Similar issue with exec_cli: no mention of shell escape rules, piping support, or how the tool handles command injection.
Security gap: No mention of permissions, authentication, or sandboxing: exec_cli and execute_code run arbitrary commands and code on the host system. No tool describes what permissions are required, what a compromised agent could do, or what safeguards prevent escalation. No mention of audit logging, secret filtering, or sandbox isolation. For a tool marked 'YOLO mode', the risk is acknowledged but not mitigated.