Loading ToolBench
MCP server that gives Claude eyes and hands in the physical world — Mac screen, webcam, phone cameras, phone screens, and security cameras
claude-eyes provides 7 tools with complete input schemas and descriptions. Naming is action-verb based (take_screenshot, capture_webcam, phone_control, mac_control). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. However, output schemas are entirely undocumented, LLMs cannot predict what fields to expect from responses. Parameter descriptions are present but inconsistent: some params (e.g., 'action' in phone_control) have nested object schemas with good descriptions, while others lack format/constraint details. Error handling is minimal, no guidance on recovery, retryability, or actionable error messages. Security is a concern: mac_control and phone_control are destructive tools with no confirmation/dry-run pattern. No tool annotations (readOnlyHint/destructiveHint) despite clear read vs. write distinctions.
Capture a single frame from the Mac webcam and return it as an image. Use this to see what is in front of the computer.
Grab a single frame from a network camera (security camera, IP camera, NVR channel) configured in ~/.claude-eyes/cameras.json. Supports RTSP, HTTP snapshot, and MJPEG URLs. Use this to see what a security or IP camera sees right now.
Get the latest frame captured from the phone camera. The user must have the phone camera page open at https://<mac-ip>:3456. Use this to see what the user is pointing their phone at.
Control any Mac application using AppleScript and shell commands. Can focus apps, click UI elements or coordinates, type text, send keystrokes, click menu items, open apps, and run shell commands. Combine with take_screenshot to create feedback loops: act, screenshot, observe, act again. Caution: keystrokes and clicks go to the real screen — if the user may be actively using the Mac, prefer app-targeted actions (pass "app") over blind coordinate clicks.
Control a connected phone: tap, swipe, type, press keys, launch/terminate apps, open URLs. Android needs only adb; iOS Simulator supports app lifecycle via simctl (touches need WebDriverAgent); physical iPhone supports launch/terminate via USB tunnel, and touch input once WebDriverAgent is set up (scripts/setup-ios-control.sh). Combine with phone_screenshot for see-act-see loops. Coordinates: use pixel coordinates from phone_screenshot — iOS taps are auto-scaled from pixels to points.
No output schemas documented. LLMs cannot predict response structure (fields, types, pagination). Forces agents to guess what data is available after each call.
Destructive tools (phone_control, mac_control) lack confirmation/dry-run pattern. Agents can execute irreversible actions (delete files, terminate apps, send keystrokes) without user approval.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read-only tools from dangerous write tools without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Take a screenshot of a connected phone's SCREEN (not its camera) — an Android device via adb, a booted iOS Simulator, or an iPhone via USB. Use this to see the app being tested on the device, e.g. after a build installs or to verify a UI change on the real phone.
Take a screenshot of the current Mac screen and return it as an image, plus a text block with the pixel-to-screen-point mapping (use it to compute click_at coordinates). Use this to see what is on screen, including any native app like OpenSCAD, Xcode, Figma, etc.
Error handling is absent. No recovery guidance, retryability classification, or actionable error messages. Agents cannot self-correct on failures.
Parameter constraints underspecified. 'max_width' in take_screenshot lacks min/max bounds. 'camera' in get_camera_frame lacks format guidance. LLMs may pass invalid values.