Loading ToolBench
Give your AI agent its own Windows machine: remote PowerShell, file transfer, screenshots, and full desktop control (computer use) over HTTP, secured with per-user keys, roles, command policies, mTLS, and an audit log.
WinReach has 12 tools with basic naming and descriptions, but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (powershell_execute, mouse_click, file_upload), which is good. However, most tools lack detailed parameter descriptions beyond the parameter name itself. Input schemas are present but minimal, many parameters have only type and description fields with no constraints, ranges, or validation guidance. Output schemas are not documented. Error handling is not visible in the tool definitions. The server implements HTTP transport (Streamable HTTP via Express), which is current. However, the tool definitions themselves show limited LLM-optimization: descriptions are terse (10-50 chars), parameter constraints are missing (e.g., keyboard_press accepts any string for 'key' with no enum), and no guidance on when to use similar tools (e.g., powershell_execute vs powershell_send). Security-critical tools like powershell_execute and file_upload lack explicit permission gates or audit trail documentation in their definitions.
Download a file from the remote system
Upload a file to the remote system
Press a keyboard key
Type text using the keyboard
Click the mouse at the current position
Move the mouse cursor to a specific position
Scroll the mouse wheel
Close a persistent PowerShell session
Parameter descriptions are minimal (10-30 chars) and lack actionable constraints. E.g., keyboard_press 'key' parameter has no enum of valid keys (Enter, Tab, Escape, etc.), forcing LLMs to guess. mouse_move 'x' and 'y' lack range constraints (0-width, 0-height). file_upload 'data' lacks format guidance (base64 encoding not explicitly stated in description).
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data. E.g., screenshot returns what? Base64 image? File path? Dimensions? powershell_execute returns stdout/stderr/exit code? This forces LLMs to infer structure from trial and error.
No error handling guidance in tool definitions. What happens if powershell_execute fails? Does it return stderr? An error code? How should the LLM retry? What if file_upload exceeds max file size? No recovery hints provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Execute an isolated PowerShell command
Open a persistent PowerShell session for stateful command execution
Send a command to an open PowerShell session
Capture a screenshot of the desktop
Tool descriptions lack context on when to use similar tools. powershell_execute vs powershell_send vs powershell_open_session are not clearly distinguished in descriptions. An LLM must infer from names alone that open_session + send + close_session is for stateful work, while execute is for isolated commands. Explicit guidance needed.
Security-critical tools (powershell_execute, file_upload, keyboard_type) lack permission/scope declarations in definitions. No indication of what roles/principals can invoke them, or what audit trail is expected. Definitions should state 'Requires: execute:powershell' or similar.