Loading ToolBench
Windows desktop GUI for Oh My Pi (OMP) - a desktop application providing workspace management, session handling, file operations, and integration with an AI coding agent
VesPi exposes 11 computer-use tools with basic descriptions and input schemas. However, critical gaps undermine production readiness: (1) Most descriptions are under 50 chars and lack context on WHEN to use each tool or what happens on failure. E.g., 'Ping the computer-use sidecar to verify connectivity' (54 chars) omits retry guidance; 'Type text into the focused window' (34 chars) lacks error handling hints. (2) Input schemas present but minimal, parameters lack constraints (enums, ranges, patterns). E.g., 'click' accepts x/y as unbounded numbers with no pixel range or DPI guidance; 'key' accepts arbitrary strings with no enum of valid key names. (3) No output schemas documented, LLMs cannot predict what fields to expect from responses. (4) No error handling guidance, tools return success/failure but do not guide recovery. (5) Parameters accept opaque IDs (window_id, element_id) without accepting human-readable alternatives. (6) No idempotency or confirmation patterns for destructive operations (click, type, key all modify system state). Average tool description length ~60 chars vs. baseline 194 chars.
Capture a screenshot of the screen or a specific window region
Inject a mouse click at specified coordinates
Focus a specific window by its identifier
Invoke an action on an accessibility element
Press keyboard keys
List all open windows on the system with their information
Ping the computer-use sidecar to verify connectivity
Get information about the screen and display configuration
Scroll the mouse wheel at specified coordinates
Descriptions too brief and lack context. 7 of 11 tools have descriptions under 50 chars (vs. baseline 194 chars). Missing WHEN to use, error recovery hints, and prerequisites. E.g., 'Type text into the focused window' (34 chars) does not explain what happens if no window is focused or if text contains special characters.
Input parameters lack constraints and enums. 'click' accepts unbounded x/y numbers with no pixel range, DPI guidance, or coordinate system documentation. 'key' accepts arbitrary strings with no enum of valid key names (e.g., 'Enter', 'Shift', 'Control'). 'button' in click is a free string, not an enum.
No output schemas documented. LLMs cannot predict response structure. E.g., 'list_windows' returns what fields? window_id, title, bounds, state? 'capture' returns base64 PNG or raw bytes? 'uitree' returns what accessibility tree format? Undocumented outputs force LLMs to guess and risk parsing failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Type text into the focused window
Get the accessibility tree of the current window as readable text
No error handling guidance. Tools modify system state (click, type, key, focus_window) but do not document failure modes or recovery steps. What happens if click coordinates are off-screen? If type is called with no focused window? If key name is invalid? LLMs receive no guidance on retry or fallback.
Parameters require opaque IDs (window_id, element_id) without accepting human-readable alternatives. LLMs must call list_windows first to discover window_id, then call focus_window, two round-trips for a simple action. No support for window title or element name lookup.