Loading ToolBench
A Model Context Protocol server for Windows desktop automation, providing tools for UI interaction, system management, diagnostics, and file operations with policy-based guardrails and audit logging.
37 tools with highly variable quality. Most lack visible input schemas in source code, only test files and tool registration files examined, not actual schema definitions. Descriptions range from adequate (Snapshot, Screenshot) to vague (App, Process). No evidence of parameter-level descriptions or type constraints. Tool names follow verb_noun convention (good), but many combine multiple concerns (App does launch+switch+resize; MultiEdit does sequential edits). Error handling and output schemas not documented in visible code. Security-critical tools (PowerShell, Registry, FileSystem, Credentials) lack clear permission gates or input validation guidance.
Launch, switch, resize, and manage applications and windows.
Execute a plan previously returned by Plan, identified by its plan_id. Re-checks device posture, then runs the steps in order, stopping at the first that fails or is refused. The steps run exactly as proposed — their arguments come from the approved plan, not from this call.
Assert expected UI state for test verification.
Capture evidence (screenshots, logs, state) for test reporting.
Perform a mouse click at specified coordinates or on a UI element.
Read from or write to the system clipboard.
Manage credentials installed at init. Secrets can be injected into fields but never read back.
Input schemas not visible for 36 of 37 tools. Only Plan shows a partial schema in source. Cannot verify parameter types, constraints, or descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
Query display configuration and monitor information.
Query Windows Event Log entries.
Read, write, copy, move, delete, list, and search files.
Extract text content from UI elements.
Query the current device posture and policy compliance status.
Invoke a UI element action through the accessibility tree.
Gracefully stop the server or trigger containment actions.
Launch an executable file with specified arguments.
Move the mouse cursor to specified coordinates.
Edit multiple UI elements in sequence.
Select multiple UI elements.
Query network configuration and connectivity information.
Display system notifications to the user.
Install, remove, list, and search software via winget and MSI.
Propose a sequence of tool calls to be adjudicated as a whole before any of it runs. Returns a change manifest (what the plan would touch, grouped and flagged) and a plan_id. Nothing is executed; call Apply with the plan_id to run it.
Execute arbitrary PowerShell commands.
List, query, or terminate system processes.
Manage session recording of desktop activity.
Read or write Windows Registry keys and values.
Create, modify, or run Windows scheduled tasks.
Fetch and extract web page content, optionally via the active browser's DOM.
Capture a screenshot of the current desktop display.
Scroll within a UI element or window.
Query, start, stop, or manage Windows services.
Send keyboard shortcuts (e.g., Ctrl+C, Alt+Tab).
Capture the current state of the desktop UI tree, including element hierarchy, properties, and accessibility information.
Query system and hardware information.
Type text input into the focused element.
Wait for a specified duration or condition.
Wait for a UI element to appear or reach a specific state.
Multi-concern tools violate single-responsibility principle. App combines launch+switch+resize+manage. MultiEdit does sequential edits. These should split into focused tools (launch_app, switch_app, resize_window; edit_element).
Destructive/security-critical tools (PowerShell, Registry, FileSystem, Credentials, Process, ScheduledTask, Package) lack visible permission gates, input validation rules, or error recovery guidance in source.
No output schemas documented in visible code. LLMs cannot infer what fields to expect from tool responses, forcing guesswork on downstream tool chaining.
Descriptions are generic and lack LLM-optimized guidance. Most are 40 - 70 chars (below 194-char baseline). None explain WHEN to use vs similar tools, prerequisites, or recovery paths for errors.