Loading ToolBench
Screen capture/recording CLI (and MCP server) driven by the XDG Desktop Portal
Three tools with clear action verbs (capture, start_recording, stop_recording) and reasonable descriptions (60-180 chars). However, critical gaps: start_recording has optional parameters but no enum constraints or validation guidance; descriptions lack WHEN/WHY context for LLM selection; no output schemas documented; error handling is generic (returns String errors with no recovery guidance); no parameter descriptions for optional fields (what does 'path' default to exactly? what audio format?). Naming is verb-first and clear, but parameter documentation is sparse. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (capture=READ_ONLY, start/stop=WRITE).
Initiate a screen capture via the system's screenshot picker and return the saved file's location
Start recording a screencast via the system's screen-share picker, optionally with desktop audio (the default sink's monitor) as a second track. Blocks until the user completes that picker and recording has actually begun. Call stop_recording to finish and get the saved file's location - only one recording can be in progress at a time.
Stop the in-progress recording started by start_recording and return the saved file's location.
No output schemas documented. Tools return file paths (strings) but LLMs cannot infer structure, type, or downstream chaining. E.g., does capture() return a URI, file path, or both? Can start_recording output be passed to another tool?
Optional parameters lack descriptions. start_recording has 'path' (Option<String>) and 'audio' (Option<bool>) but no guidance on defaults, format, or constraints. Parameter descriptions are missing entirely.
No tool annotations despite clear risk profiles. capture is READ_ONLY, start_recording and stop_recording are WRITE/destructive. Missing readOnlyHint and destructiveHint annotations prevent LLMs from reasoning about safety and idempotency.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Error handling returns generic String errors with no recovery guidance. E.g., 'capture failed: <err>' tells LLM nothing about whether to retry, ask user, or give up. No error classification (retryable vs fatal).
Descriptions lack WHEN/WHY context. 'Initiate a screen capture' is WHAT, but not WHEN to use it vs alternatives, or what prerequisites exist (e.g., X11/Wayland, XDG Desktop Portal availability).