Loading ToolBench
Plugin-ready MCP server for launching and capturing visible Windows application windows.
Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. run_and_capture has a compound name ('and') suggesting multiple responsibilities. Descriptions are adequate (100-200 chars) but lack actionable guidance on when to use each tool vs. alternatives. Parameter descriptions are present but inconsistent in detail, some lack constraints (e.g., wait_ms has no min/max bounds). Output schema is partially documented in code but not formally specified in tool definitions. Error handling returns text but lacks recovery guidance or error classification.
Capture a screenshot of an already-running window by process id, or by title as a fallback. Returns the screenshot as an inline image and saves it to disk.
List all visible windows on the desktop with their titles and process information. Use this to discover which windows are available for capture.
Launch a Windows executable, wait for its window to appear, and capture a screenshot. If the process is already running, captures the existing window. If capture fails on the existing process, kills it and relaunches. Supports multi-frame capture with configurable intervals. Returns the screenshot as an inline image and saves it to disk.
Tool name 'run_and_capture' contains 'and', signaling multiple responsibilities (launch executable AND capture screenshot). Should split into separate tools or rename to reflect primary action.
Numeric parameters lack bounds. wait_ms, capture_count, and capture_interval_ms have no min/max constraints, allowing LLMs to pass absurd values (e.g., wait_ms=999999999) that cause timeouts or resource exhaustion.
Output schema not formally documented in tool definitions. Code shows buildCaptureResponse() returns images and text, but tool descriptions do not specify return structure, field names, or types. LLMs cannot plan downstream operations without knowing what fields to expect.
Error responses lack recovery guidance. Errors return plain text (e.g., 'Error: ...') without suggesting next steps or categorizing as retryable vs. user-fixable. LLM cannot determine whether to retry, ask user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Parameter 'window_title' is optional in run_and_capture but its interaction with process matching is undocumented. Does it filter by exact match, substring, or regex? What happens if multiple windows match?