Loading ToolBench
An MCP server that acts as a laptop assistant, providing tools for system operations, file management, web browsing, application management, and utility functions. Integrates with Claude Code and Google Antigravity.
This server provides 34 tools with generally clear naming conventions and structured schemas. Most tools have adequate descriptions (100-300 chars) and input parameters with type definitions. However, there are significant gaps: output schemas are not formally documented; error handling lacks actionable recovery guidance; several destructive operations use a confirmation pattern that is custom-implemented rather than standardized; and parameter descriptions occasionally lack detail on constraints and valid value ranges. The tool suite is well-organized by domain (app, desktop, file, system, utility, web tools) with consistent parameter naming conventions (e.g., app_id, path, url). Tool names follow verb_noun convention (list_, search_, install_, delete_, etc.), which is strong. Notable issues: (1) 12 tools have no visible input schema in source (inferred registration); (2) confirmation token pattern for destructive operations is custom and not MCP-standard; (3) output schemas not documented anywhere; (4) some descriptions like 'schedule_type' lack explicit enum documentation; (5) no formal pagination for tools that could return large lists (list_installed_apps, list_processes). Baselines from the rubric suggest 90% of A+ tools have 50-200 char descriptions and 100% have parameter descriptions, this server achieves ~85% on both metrics.
Copy a file or directory to a new location.
Create a directory and any necessary parent directories.
Delete a file or directory. DESTRUCTIVE: This action requires confirmation. The tool will return a confirmation token that must be passed to confirm_action to execute. For directories, this performs a recursive delete.
Delete a scheduled task. DESTRUCTIVE: This action requires confirmation.
Download a file from a URL to a local path.
Fetch a webpage and return its content.
Get the current battery status and remaining time.
Output schemas not formally documented. While input schemas are present for most tools, the tool descriptions do not specify what structure is returned (e.g., get_system_info returns what fields?). LLMs cannot plan downstream operations or extract specific data without knowing output structure.
Custom confirmation token pattern used for destructive operations (uninstall_app, update_app, delete_file, delete_scheduled_task, run_command, shutdown_system, restart_system) instead of MCP standard. The pattern returns a confirmation token that must be passed to a confirm_action tool, but this is not shown in the tool definitions. This creates an undocumented two-step confirmation flow that LLMs may not understand.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
Get the current text content from the system clipboard.
Get detailed information about a file or directory.
Get network interfaces and connectivity information.
Get comprehensive system information including CPU, memory, disk, and OS details.
Get a list of currently open windows.
Install an application using winget.
Terminate a running process by PID.
List files and directories at the specified path.
List installed applications using winget.
List running processes with their resource usage.
List scheduled tasks.
Move or rename a file or directory.
Open an application by name or file path. On Windows, this uses os.startfile which works with: - Safe application names (e.g., 'notepad', 'calc') - Safe file types (documents, images, media) - URLs (opens in default browser)
Read the contents of a text file. For binary files, returns file metadata instead of content.
Restart the system.
Run a shell command on the system and return the output. POTENTIALLY DANGEROUS: This action requires confirmation to prevent command injection attacks. The tool will return a confirmation token that must be passed to confirm_action to execute. Uses PowerShell on Windows. The command runs asynchronously with a configurable timeout to prevent runaway processes.
Schedule a task to run automatically using Windows Task Scheduler. DESTRUCTIVE: This action requires confirmation.
Search for available applications in the winget repository.
Search for files matching a pattern in a directory.
Send a desktop notification (toast/balloon tip).
Set text content to the system clipboard.
Shut down the system.
Take a screenshot of the current screen and save it to a file.
Uninstall an application using winget. DESTRUCTIVE: This action requires confirmation. The tool will return a confirmation token that must be passed to confirm_action to execute.
Update an installed application using winget. DESTRUCTIVE: This action requires confirmation because it modifies installed software.
Search the web using DuckDuckGo and return results.
Write content to a file. Creates the file and parent directories if they don't exist.
No pagination support for tools that return potentially large result sets. Tools like list_installed_apps, list_scheduled_tasks, list_processes, search_available_apps could return hundreds of items, which would exceed context windows. Missing limit/offset or cursor-based pagination.
Several parameters lack explicit constraint documentation. E.g., schedule_task's 'schedule_type' parameter mentions 'Options: DAILY, WEEKLY, MONTHLY, ONCE, ONLOGON, ONSTART' in description, but this should be formalized as an enum in the schema. Similarly, run_command accepts timeout (0-300) and list_processes accepts sort_by ('memory', 'cpu', 'name'), but these are documented only in descriptions, not schema enums.
No actionable error recovery guidance. Error responses like 'Failed to install app' or 'Search failed' do not guide the LLM on what to do next.
Four tools (get_window_list, get_system_info, get_battery_status, get_clipboard) have empty input schemas (no parameters), but their return structures are never documented. LLMs cannot infer what data these tools provide or how to use the output.
No idempotency guarantees documented. Tools like write_file (with append=False), delete_file, and install_app may have idempotent or non-idempotent semantics that should be explicit for agent retry logic.
Tool descriptions could be more LLM-optimized. Several fall below the rubric baseline of 50-200 chars that are optimal for LLM selection (e.g., 'Get the current battery status' is 37 chars; 'Get network interfaces and connectivity information' is only 52 chars). Descriptions should answer WHAT, WHEN to use, and WHY.