Loading ToolBench
MCP server binary exposing 54 Ghost desktop, browser, and shell automation tools over stdio JSON-RPC
Ghost MCP presents a comprehensive desktop automation toolkit with 31 tools. Strengths: all tools have descriptions (10-100 chars avg), all have input schemas with type definitions, and parameter descriptions are generally present. Major weaknesses: descriptions are often too brief (20-50 chars) to guide LLM selection; parameter descriptions lack detail on format/constraints; output schemas are undocumented; error handling guidance is absent; tool composition has overlapping responsibilities (e.g., ghost_act vs ghost_click vs ghost_click_at; ghost_find vs ghost_ground_locate); no pagination for list operations; security considerations not documented. The naming follows verb_noun pattern well, but some tools conflate multiple concerns (ghost_act combines find, focus, AND action). Parameter types are present but enum constraints are underutilized, e.g., ghost_see 'mode' enum is good, but ghost_find 'mode' lacks explanation of practical differences. No visible error handling guidance in descriptions; responses lack documented structures for chaining (e.g., does ghost_find return screen coordinates the agent can pass to ghost_click_at?). Overall: solid foundation with clear naming and schemas, but insufficient detail for production LLM confidence.
Atomic find→focus→action in one call. Supports click, type, double_click, right_click, hover actions.
Close a browser tab via Chrome DevTools Protocol.
Evaluate JavaScript in the browser context via Chrome DevTools Protocol.
List open browser tabs via Chrome DevTools Protocol.
Navigate browser to a URL via Chrome DevTools Protocol.
Capture browser viewport screenshot via Chrome DevTools Protocol.
Clear the element cache.
Retrieve a cached element by its ID.
Overlapping tool responsibilities: ghost_act, ghost_click, ghost_click_at, and ghost_find all perform similar grounding/action operations. LLMs will struggle deciding which to call. Should consolidate into a clear hierarchy or split by concern.
Output schemas are not documented. Tools return data (coordinates, element metadata, lists, screenshots) but descriptions do not specify field names, types, or structure. LLMs cannot plan downstream tool calls without knowing what they receive.
Descriptions are too brief (most 45 - 60 chars) and lack actionable guidance. E.g., 'Key input.' does not explain key format, modifiers, or when to use ghost_key vs ghost_hotkey vs ghost_press. Descriptions under 100 chars cannot guide LLM tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
List all cached elements.
Click a UI element by name or role.
Click at absolute screen coordinates.
Describe interactive elements in a window (or all windows) as JSON.
Ground a target via the cascade: cache→UIA→OCR→VLM. Returns center, rect, source.
Bring a window to the foreground by partial name match.
Read the clipboard.
Ground a UI target using the hybrid grounding cascade (UIA→OCR→VLM).
Press a hotkey combo. Example: Ctrl+C
Execute a structured intent with multiple automation steps.
Key input. Single key: 'Enter'. Combo: 'Ctrl+C'. Hold: 'down:Shift' / 'up:Shift'.
Launch an executable. Prints the PID.
List visible top-level windows as JSON.
Press a key: Enter, Tab, Escape, F5, ArrowUp, etc.
Extract structured data from the screen via UIA name-matching + VLM fallback.
Execute a JSON intent file or stdin (pass `-` for stdin).
Capture primary monitor to a PNG file.
Describe the active screen's UI elements with optional filtering by window and sequence number
Write text to the clipboard.
Take a screenshot. Output to --out file (PNG) or print JPEG base64 to stdout.
Type text into a UI element by name or role.
Window management. Operations: list, focus, state, launch.
Set window state: maximize, minimize, restore, close.
Parameter descriptions lack format/constraint details. E.g., ghost_key 'keys' param description says 'Key sequence to press' but does not clarify syntax: Is it 'Ctrl+C' or 'Control+C'? Can modifiers be combined? The example suggests yes, but LLMs cannot infer from examples alone.
Duplicate/similar tools without clear distinction: ghost_snapshot vs ghost_screenshot (both capture screen), ghost_find vs ghost_ground_locate (both ground targets), ghost_window vs ghost_focus_window/ghost_window_state (window operations). LLMs will waste reasoning cycles or pick the wrong one.
No error handling guidance in tool descriptions. Tools will fail (element not found, window closed, permission denied, timeout), but descriptions do not tell the LLM what to do next. Should include recovery hints like 'If element not found, try ghost_describe to inspect the screen'.
No pagination or result limits documented. Tools like ghost_list_windows, ghost_describe, ghost_query, ghost_browser_list_tabs, ghost_cache_list may return large result sets. Without pagination/limits, responses can bloat context. Should cap results and offer page/offset parameters.
Tool chaining IDs not documented. E.g., ghost_find likely returns element coordinates or IDs, does it return a value ghost_click_at can use? Does ghost_list_windows return window names that ghost_focus_window accepts? Responses must include IDs downstream tools expect.
Parameter types present but enums underutilized. Many parameters accept free-form strings where enums would prevent hallucination. E.g., ghost_window 'state' has enum (good), but ghost_key 'keys' is free-form (bad). Should define enums for all constrained inputs.
Destructive operations (ghost_cache_clear, ghost_window_state close, ghost_run, ghost_launch) lack confirmation or dry-run capability. Agents can easily wipe caches or close windows by mistake. Should require explicit confirm or return a 'confirm_required' result.