Loading ToolBench
MCP server for interactive user feedback with screenshot capture and command execution.
The server defines a single tool 'interactive_feedback' with partial schema and minimal descriptions. The tool name lacks a clear action verb (should be 'get_feedback' or 'request_user_feedback'). The input schema is present but several parameters lack descriptions. The output schema is not documented at all. Error handling is minimal, there is no guidance for recovery or classification of failure modes. The tool appears to perform UI interaction (screenshot capture, command execution, user interaction) but these critical behaviors are not documented in the description or parameter details. Security concerns are present: the tool modifies project state (installs hooks) and executes commands, but there is no documented permission gate, audit logging, or validation of destructive operations.
Request interactive user feedback with optional screenshot capture and command execution.
Tool name does not start with action verb. 'interactive_feedback' is ambiguous, it could mean request feedback, send feedback, or process feedback. Should be 'request_user_feedback' or 'get_user_feedback'.
Tool description (135 chars) is generic and does not explain WHAT the tool does, WHEN to use it, or WHAT it returns. It mentions 'optional screenshot capture and command execution' but does not document whether these are performed automatically, requested by user, or configurable. No mention of side effects (hook installation, state modification).
Input parameters lack descriptions or have minimal descriptions: 'predefined_options' (13 chars), 'tab_title' (27 chars), 'tab_id' (26 chars). These descriptions are too short to guide LLM usage (rubric baseline minimum 20 chars for meaningful guidance). Parameter 'project_directory' description is clear, but others fail to explain purpose, constraints, or valid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Output schema is completely undocumented. The source code shows the tool responds with a dict containing 'response' (user selection), 'screenshot' (base64 image), and 'exit_code' (command result), but none of this structure is declared in the tool registration. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields are returned.
No error handling documentation. The tool can fail in multiple ways (daemon timeout, socket connection failure, user cancellation, command execution error) but there is no guidance for what error messages mean, whether failures are retryable, or what the LLM should do next.
Destructive operations (hook installation, command execution, file writes to .cursor directory) are not gated behind permission checks or confirmation steps. The tool modifies project state without explicit user consent via the LLM. No audit trail is documented.
Tool performs multiple concerns: (1) request user feedback, (2) capture screenshot, (3) execute commands, (4) install hooks. This violates the single-responsibility principle. Should be split into separate tools: 'request_user_feedback', 'capture_screenshot', 'execute_command'.
Code injection risk: 'project_directory' is used to construct file paths and shell hook scripts without documented sanitization. Tool accepts user-controlled project_directory from the LLM and uses it to write to .cursor/hooks.json and execute shell scripts. No validation against path traversal or command injection.
Parameter 'predefined_options' is an array of strings but has no constraints on array length, string length, or valid values. LLMs could pass 1000+ options or extremely long strings, causing UI rendering failures or resource exhaustion.
No idempotency guarantee. Calling the tool twice with the same inputs may install hooks twice or create duplicate lock files. This breaks the idempotent-operation pattern and can cause side effects if the LLM retries on timeout.