Loading ToolBench
Top-level macOS computer-use skill with a bundled standalone runtime and MCP server, zero local Claude dependency. Provides computer control and automation capabilities for macOS.
Mixed quality across 23 tools. Most tools have descriptions (good) and some parameter type information, but critical gaps exist: (1) Most tools lack output schema documentation, LLMs cannot plan downstream calls or extract results. (2) Many parameters lack type constraints or detailed format guidance. (3) Some descriptions are too brief (20-40 chars) to guide LLM decision-making. (4) No tool has explicit error guidance or recovery paths. (5) Tool naming is functional but some are generic (e.g., 'key', 'holdKey'). The average tool scores 58/100; no individual tool reaches 70.
Returns information about the application window at the specified coordinates
Performs a mouse click at the specified coordinates with optional button, count, and modifier keys
Drags the mouse from one position to another
Finds which displays contain windows from specified applications
Returns the current mouse cursor position
Returns geometry information for a specific display
Returns information about the currently frontmost (active) application
Holds down one or more modifier keys for a specified duration
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, forcing them to guess downstream parameter mappings and risking failed chaining calls.
Multiple tools with bare-minimum descriptions (20-40 chars). 'mouseDown' and 'mouseUp' descriptions are too brief to guide LLM selection: 'Presses and holds the left mouse button' (39 chars) vs. ideal 50-200 char range. Lack context for when to use.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Presses keyboard key combinations or sequences
Returns information about all connected displays
Returns a list of installed applications on the system
Returns a list of currently running applications
Presses and holds the left mouse button
Releases the held left mouse button
Moves the mouse cursor to the specified coordinates
Launches or brings to foreground an application by bundle identifier
Prepares the system for computer use actions by ensuring permissions and visibility
Reads the current contents of the clipboard
Captures a screenshot of the specified display and returns it as base64-encoded JPEG data with display geometry information
Scrolls the mouse wheel at specified coordinates
Types text at the current cursor position, optionally using the clipboard for pasting
Writes text to the clipboard
Captures and zooms into a specific region of the screen
Parameter constraints missing or underspecified. 'jpegQuality' in screenshot accepts 0.0-1.0 but no validation constraint shown. 'displayId' in multiple tools lacks enum/range bounds. LLMs may pass invalid values.
No error handling or recovery guidance visible in tool definitions. Tools like 'openApp', 'listInstalledApps' provide no documentation of failure modes (app not found, permission denied) or how LLM should retry.
Generic naming: 'key' and 'holdKey' lack clarity. 'key' could mean read a keypress, check a dictionary key, or press a keyboard key. Better names: 'pressKey', 'holdModifier'. Tool names should start with action verbs and disambiguate intent.
List tools ('listInstalledApps', 'listRunningApps', 'listDisplays') have no documented pagination support, limits, or result structure. Large result sets could exhaust context window without pagination parameters or return count.
Parameter 'modifiers' in 'click' and 'keySequence' in 'key' accept arrays/strings but lack explicit enum constraints or format validation. LLM may invent invalid modifier names ('meta', 'option' vs 'cmd', 'alt').
No documentation of which tools are idempotent vs. destructive. 'click', 'type', 'scroll' are idempotent if coordinates match, but LLM cannot infer this. Tools should declare idempotency hints.