Loading ToolBench
AppleScript for Windows — MCP server for AI agents. Control any Windows app from Claude, ChatGPT, or any MCP client.
WinScript MCP has 52 tools with significant definition quality gaps. Most tools have minimal descriptions (10-50 chars, far below the 194-char production baseline), missing input schemas for several tools, and lack structured output documentation. While tool names follow verb_noun conventions well (open_app, close_app, excel_read_cell), parameter descriptions are sparse or absent entirely. No error handling guidance, no security annotations, and no permission/scope declarations. The codebase shows tool registrations in server.py via FastMCP decorators, but the provided code snippets are incomplete, actual parameter schemas and return types are not visible for full assessment. Many tools expose security risks (run_powershell, delete_file, outlook_send_email) without permission gates or audit mechanisms. The audit logging layer exists in code but is not integrated into tool responses, so LLMs have no visibility into error categorization or recovery paths.
Close the current Chrome tab.
Search for text on the current Chrome page.
Get the title of the current Chrome page.
Read current URL from Chrome address bar.
Navigate to a URL in Chrome. Example: chrome.navigate("https://github.com")
Open a new tab in Chrome.
Open Google Chrome, optionally navigating to a URL.
Most tools lack input schemas. 30+ tools (click, type_text, read_text, press_key, get_ui_tree, coordinate_click, all file operations, all Excel operations except open/save/close, all Outlook operations, chrome_get_url, chrome_get_title, chrome_new_tab, chrome_close_tab, notepad_save, outlook_open, workflow_record_stop, workflow_record_discard, workflow_list) have no visible parameter definitions in source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Perform a mouse click at coordinates or on a UI element.
Close a window by title (partial match).
Perform a mouse click at specific screen coordinates.
Copy a file to a new location.
Delete a file.
Close an open Excel file.
Open an Excel file.
Read a value from a specific Excel cell.
Read a range of cells from Excel.
Save an open Excel file.
Write a value to a specific Excel cell.
Navigate Explorer to a path. Example: explorer.navigate("C:/Users")
Open Windows File Explorer, optionally navigating to a path.
Check if a file exists.
Bring a window to the foreground by title (partial match).
Get information about the currently active/focused window.
Read the contents of the clipboard.
List all open windows with titles and PIDs.
Get current desktop state snapshot. Active window, all open windows, clipboard preview. Use this before any action sequence to establish baseline.
Get the UI element tree/hierarchy from a window.
List files and directories in a path.
Move a file to a new location.
Close Notepad.
Open Notepad, optionally opening a file.
Save the current Notepad file.
Type text into Notepad.
Open a Windows app by name or alias. wait_seconds: pause after launch.
Open Microsoft Outlook.
Read emails from Outlook inbox.
Send an email via Outlook.
Press a keyboard key or key combination.
Read the text content of a file.
Read text from a UI element or window.
Execute a PowerShell command.
Set the contents of the clipboard.
Capture a screenshot of the screen.
Type text into a focused window.
Wait for a window to appear. Important for slow-loading applications. Example: wait_for_window("Notepad", 5)
Delete a saved workflow by name.
List all saved workflows with step counts and run history.
Discard current recording without saving.
Start recording a workflow. All subsequent tool calls are captured. Example: workflow_record_start("daily_report","Opens report and emails it")
Stop recording and save the workflow. Example: workflow_record_stop()
Replay a saved workflow by name. dry_run=True shows steps without executing. Example: workflow_replay("daily_report"), workflow_replay("daily_report", dry_run=True)
Write text content to a file.
Descriptions are uniformly brief (10-50 chars), far below production baseline of 194 chars. Most tools have single-line statements like 'Perform a mouse click at coordinates or on a UI element.' with no context for WHEN to use them, WHAT they return, or error handling guidance. LLMs cannot distinguish between click (coordinate-based) and coordinate_click (appears identical).
No error handling guidance. Tools like delete_file, run_powershell, and outlook_send_email are irreversible/destructive but do not document: (a) what errors can occur, (b) whether they are retryable, (c) recovery steps. The audited() wrapper catches exceptions but does not surface error classification to the LLM. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
No permission gates or scope declarations. Destructive tools (delete_file, run_powershell, workflow_delete) and sensitive tools (outlook_send_email, set_clipboard) lack permission checks. An untrusted agent could invoke delete_file or run_powershell without restrictions. Per pattern:permission-gate and pattern:scope-declaration, each tool should declare required permissions and enforce them at runtime.
Parameter descriptions missing or minimal. Tools like click, coordinate_click, and type_text have no visible input parameter documentation. Even tools with schemas (excel_open, chrome_navigate) lack actionable parameter descriptions explaining format, constraints, or dependencies. Per pattern:tool-description, every parameter must have a description explaining what it controls.
Duplicate/ambiguous tool names. 'click' and 'coordinate_click' appear to do the same thing (mouse click); similarly, chrome_open/excel_open/explorer_open/notepad_open are adapter wrappers. LLMs will struggle to choose between near-identical tools. Per pattern:tool naming guidance, when multiple tools operate on the same resource, names must disambiguate clearly.
No documented output schemas. Tools return unspecified formats, LLMs don't know what fields to expect. For example, get_running_apps, excel_read_range, workflow_list have no documented return structure. Per pattern:response-shaper, tool responses must be structured with typed fields so LLMs can parse and chain results.
No confirmation/dry-run patterns for irreversible operations. delete_file, run_powershell, and workflow_delete lack dry-run or confirmation steps. Agents can accidentally destroy data or execute dangerous commands. Per pattern:confirmation-request, irreversible operations should support a dry-run or ask for confirmation.
Audit logging is implemented in server.py (log_action, remember_action calls) but not surfaced to tool responses. LLMs have no visibility into audit trails or error categorization, making debugging and compliance tracking impossible from the agent perspective.
No input validation or sanitization guidance. run_powershell accepts arbitrary commands with no documented constraints. LLMs could be tricked via prompt injection into passing malicious payloads (e.g., 'Get-ChildItem | rm -r'). Per pattern:tool-gateway, all agent-provided input must be sanitized and validated.