Loading ToolBench
A Windows-only MCP server for capturing screenshots of displays, regions, and active windows, with image file management capabilities.
CaptureScreenMCP provides a coherent Windows-only screen capture toolkit with clear action verbs and generally good descriptions. However, several dimension scores are held back by inconsistent schema details, missing parameter type definitions in some tools, and the absence of structured error handling guidance. All 7 tools are registered with [McpServerTool] attributes and have descriptions (10 - 70 chars each), but parameter schemas vary in completeness. The server demonstrates reasonable naming (capture_screen, list_displays, delete_capture_images_by_datetime) and moderate parameter documentation, but lacks formal input validation, actionable error messages, and output schema documentation. No tool annotations (readOnlyHint/destructiveHint) are present despite 2 tools being marked destructive.
Capture the currently active window and save as PNG.
Capture a specific display (monitor) and save as PNG.
Capture a screen region and save as PNG.
Capture full virtual desktop and save as PNG.
Delete all capture image files in CAPTURE_SCREEN_OUTPUT_DIR.
Delete capture images by date or datetime range using file modified time.
List all connected displays with bounds and primary flag.
Missing tool annotations for destructive operations. DeleteAllCaptureImages and DeleteCaptureImagesByDatetime are marked DESTRUCTIVE in risk profile but have no readOnlyHint=false or destructiveHint=true attributes in tool definitions. This prevents clients from warning users or applying safety gates.
CaptureDisplay parameter 'display' is typed as 'object' but accepts multiple formats (integer index, string selector like 'primary/left/right', Japanese strings). Schema lacks enum constraint or oneOf union; description is verbose but parameter type is underspecified. LLMs cannot validate input before calling.
No output schemas documented for any tool. The code shows returned objects (e.g., { saved_path, display, x, y, width, height, title }) but MCP schema files do not declare these in tool definitions. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
Error handling is minimal and not recovery-guided. Code validates inputs (width/height > 0, datetime ranges, mutual exclusivity) but throws generic ArgumentException/ArgumentOutOfRangeException. No tool response indicates what the user/agent should do next (e.g., 'Region width must be > 0. Specify valid x, y, width, height coordinates.').
Parameter descriptions inconsistent in depth and formatting. CaptureRegion's 'x', 'y', 'width', 'height' have minimal descriptions ('Left coordinate', 'Top coordinate', etc.) with no range hints (e.g., '0 - screen_width'). CaptureDisplay's 'display' description is lengthy but vague on valid input formats. Pattern inconsistency confuses LLMs about what level of detail is expected.
No pagination or limits declared for ListDisplays. If a system has many displays, response could be large. No mention of cap, sorting, or cursor-based access in description.