Loading ToolBench
MCP server for Puck.app that exposes Puck's tools as MCP tool definitions for CLI providers. Handles tool dispatch, execution, timeouts, and approval workflows.
Puck MCP server has 22 tools with basic schemas and descriptions, but significant quality gaps prevent production recommendation. All tools have descriptions (10-50 chars, mostly terse) and input schemas with type definitions, but lack parameter descriptions, output schemas, and error guidance. Tool naming is generally verb-first (launch_app, list_running_apps, click_element) but some names are vague (point_at, show_code). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter schemas omit descriptions entirely, LLMs cannot infer what 'frame', 'role', or 'pid' mean without text. No documented output schemas, pagination, or recovery guidance. Security-critical tools (run_shell, run_applescript) lack confirmation patterns or dry-run support.
Get a snapshot of what is in an application window before asking about specific elements
Click on a UI element at the specified frame
Spawn an ACP agent through CodeEditorRunner for code editing tasks
Find a UI element in an application window
Get information about the frontmost window
Launch an application by name or bundle ID
List files in a directory
Parameter descriptions completely missing. All 22 tools have input schemas with type definitions but zero parameter descriptions. LLMs cannot infer what 'frame', 'pid', 'role', 'hold_seconds', or 'lines' mean without text guidance. This violates pattern:tool-description and forces LLMs to guess.
No output schemas documented. Tools return data but LLMs have no specification of response structure, field types, or required fields. This prevents downstream tool chaining and forces LLMs to infer structure from examples.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
List all currently running applications
Open a file in the editor pane
Open a task session (ai-module executor, never dispatched)
Walk the pet to a point on screen and hold it there
Press a key in the focused application
Read the contents of a file
Run an AppleScript
Run a shell command
Scroll in a direction within a frame
Highlight lines in the editor and walk the pet to the pane with a caption
Read output from a running terminal session
Send input to a running terminal session
Start a long-running terminal session (dev server, watcher, build with no end)
Stop a terminal session or all sessions if no ID provided
Type text into the focused application
Destructive tools lack confirmation or dry-run patterns. run_shell and run_applescript can delete files, modify systems, or cause data loss, but have no confirmation step, dry-run mode, or recovery guidance. Agents will execute irreversible commands without safeguards.
Tool annotations missing. Despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY), no tools carry readOnlyHint, destructiveHint, or idempotentHint annotations. LLMs cannot distinguish safe from dangerous operations without explicit hints.
Vague tool names reduce clarity. 'point_at' does not clearly convey 'move cursor to screen coordinates and hold'. 'show_code' conflates highlighting with navigation. 'open_task_session' is cryptic. Names should start with action verbs and be self-documenting.