Loading ToolBench
Video processing application with cursor replacement, zoom animations, and Electron-based editor for creating screen recordings with physics-based animations
Cursor Flow exposes 16 tools across backend (FastAPI) and Electron components. While tool names follow verb_noun conventions and descriptions exist, the critical problems are: (1) NO VISIBLE INPUT SCHEMAS in the source code, tools are documented with parameter descriptions in the rubric but actual JSON Schema definitions are not shown in the provided source excerpt, (2) descriptions are extremely brief (many under 20 chars), (3) no documented output schemas, (4) no error handling guidance, (5) STDIO/custom transport with no evidence of remote accessibility or stateless MCP compliance. Descriptions under 20 chars score 0-20. This server appears to be a custom Electron+FastAPI hybrid, not an MCP-compliant server.
Cleanup job files after download.
Close developer tools in the main window.
Detect cursor positions in a video without cursor data. Uses computer vision to track the cursor.
Download processed video.
Get available desktop capture sources (screens and windows).
Get current mouse position.
Get primary display screen size.
NO VISIBLE INPUT SCHEMAS: None of the 16 tools show explicit JSON Schema definitions in the provided source. Tools are described in the rubric with parameter types and defaults, but actual schema objects (type, properties, required arrays) are not visible in backend/main.py or electron files.
DESCRIPTIONS TOO BRIEF: 11 of 16 tools have descriptions under 20 characters (health, stop-mouse-tracking, get-mouse-position, get-screen-size, close-devtools, get-window-bounds, get-cursor-styles, etc.). Descriptions do not explain WHEN to call the tool, WHAT it returns, or WHY it matters vs. similar tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Get main window bounds (position and size).
Get available cursor styles.
Get processing job status.
Backend health check endpoint.
Process uploaded video with cursor overlay. Returns job_id for polling status.
Reveal file in system file explorer.
Save project file to disk with optional file dialog.
Start global mouse position tracking via robotjs with 60 FPS polling.
Stop global mouse position tracking.
NO OUTPUT SCHEMAS DOCUMENTED: No tool specifies what it returns. LLMs cannot plan downstream calls without knowing fields. E.g., process_video returns 'job_id for polling status' but no schema shows the response structure or what get_status returns (job status, progress %, completion time?).
NO ERROR HANDLING GUIDANCE: Tools do not specify what errors can occur or what LLMs should do on failure. E.g., process_video may fail if video is corrupted, file is too large, or backend is down, none of this is documented. No recovery hints like 'If job not found, start a new one with process_video().'
MISSING PARAMETER DETAILS FOR process_video: 'cursor_color' parameter listed as 'Cursor color name' but no enum or valid values provided. LLMs will guess colors (red, #FF0000, 0xFF0000, etc.). Should enumerate: [white, black, red, blue, green, etc.] or specify hex format.
VAGUE PARAMETER DESCRIPTIONS: Several params lack sufficient detail. E.g., 'video' is described as 'Video file to process' but no file size limits, format restrictions (MP4, WebM, AVI?), or duration constraints are mentioned. 'cursor_data' described as 'JSON string of CursorPoint[]' but no CursorPoint schema shown.
NAMING INCONSISTENCY: Electron tools use kebab-case (start-mouse-tracking, stop-mouse-tracking, get-mouse-position) while Python tools use snake_case (process_video, get_status). LLMs expect consistent naming. Should standardize to one convention across all tools.
NO PARAMETER RANGES OR CONSTRAINTS: 'cursor_size' defaults to 48 but no min/max specified. Is 1 valid? 1000? LLMs will guess. Should state: 'Cursor size in pixels (1-256, default 48).' Same for 'quality' enum, description says 'high, balanced, fast' but should be formal enum constraint.
DESTRUCTIVE OPERATIONS NOT MARKED: cleanup_job is DESTRUCTIVE (deletes files) but has no documentation of side effects, no dry-run option, and no confirmation step. Agents may call it accidentally after download_video, losing the output forever. Should add error handling docs and consider a confirmation_required flag.
POLLING ANTI-PATTERN: process_video returns a job_id and requires polling get_status in a loop. This wastes tokens and latency. Should offer webhook callback, server-sent events, or a get_video_result tool that blocks until ready. Current pattern forces agent to implement retry logic.
COMPOSITION: 'start-mouse-tracking', 'stop-mouse-tracking', and 'get-mouse-position' are closely related but named inconsistently. Should group into a single 'mouse_tracking' tool with actions (start, stop, get) or use consistent verb_noun naming. Three separate tools create reasoning overhead.