Loading ToolBench
MCP server exposing iPhone data mirrored to PC and a job queue for live phone actions. Provides CLIP-based semantic photo search, photo/video access, geolocation clustering, and capability plugins for browser automation.
Five tools with strong, detailed descriptions (194 - 400 chars, well above baseline 194 avg). All have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun pattern (photos_search, photos_by_date, photos_open). Schemas are well-structured JSON with clear constraints (e.g., date format 'YYYY-MM-DD', bbox array structure, enum-like kinds restriction). Output schemas documented in descriptions. However, no explicit error handling guidance in tool definitions, no tool annotations (readOnlyHint/destructiveHint), and parameter descriptions could be more prescriptive about validation rules and recovery paths. Composition is sound, each tool has one clear responsibility and outputs chain into downstream tools (e.g., photos_places → photos_search/photos_by_date → photos_open).
List photos by time and/or place, newest first, with no content filtering. Use when the user asks by time alone ('last Tuesday's photos') or when a bbox already narrows things enough that ranking by appearance would only hurt.
Prepare photos and videos for you to actually look at. iPhone photos are HEIC, which the Read tool cannot display, and a video cannot be displayed at all. This converts each asset to a JPEG you can Read: a photo becomes a downscaled still, a video becomes a contact sheet of frames sampled across the clip, labelled left to right, earliest first. Read the view_path values and judge from what you SEE. For a video the sheet is a sample - if the answer might be between the frames, say so rather than claiming the clip does or does not contain something. Keep the list small - 10 to 20 at a time.
Where the user has been, and when - derived from photo GPS tags. Returns clusters of roughly 55km with photo count and first/last day, newest first. There is no geocoding database here: read the coordinates and name the places yourself. This is how you answer "find photos from my Japan trip" when you do NOT know the dates. Call this first to discover the trip's date range and coordinates, then feed those into photos_search or photos_by_date.
Semantic search over the user's photos AND videos, optionally bounded by time and place.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in tool definitions. All five tools are read-only but this is not formally signaled to the MCP client.
Error handling guidance missing from tool definitions. No recovery hints for common failure modes (e.g., 'If no results, try photos_places first'; 'If bbox excludes all results, check photos_geotagged count').
Parameter validation rules not explicitly stated in descriptions. E.g., top_k range (1 - ?), max_px range, min_photos range, bbox coordinate bounds. LLMs cannot infer these constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Size and freshness of the local photo index: how many photos, date range, how many still need embedding, and which folders are being watched. Call this first when the user asks anything about their photos.
Output schema structure not formally documented in tool definitions. Descriptions mention JSON output but do not specify field names, types, or required vs optional fields.
No pagination or result-limiting guidance in photos_by_date and photos_places. Default limit=100 for photos_by_date could return large result sets; no mention of next_cursor or offset.