Loading ToolBench
Dev Runner CLI - A daemon-based service runner for development environments with TUI and MCP server modes
This MCP server has severe definition quality gaps across all dimensions. Tool descriptions exist but are minimal (10-30 chars), falling well below the 194-char baseline. Input schemas are present in the provided specification but lack proper type definitions and comprehensive parameter descriptions. No output schemas are documented. Error handling is absent, tools provide no guidance on recovery or retry logic. Parameter naming is inconsistent (e.g., 'service' vs 'services'), and there is no distinction between idempotent reads and destructive writes in the interface. The server presents 8 tools for service lifecycle management (start, stop, restart, status, logs, clear_logs, check_ports, kill_ports), but most lack the documentation precision required for reliable LLM tool selection and composition.
Check which configured ports are in use
Clear logs for a service or all services
Kill processes running on specified ports
Get logs from services
Restart a specific service
Start services with optional port killing
Get current status of all services
Stop all running services
Descriptions are critically short (10 - 30 characters), well below the 194-character baseline. Examples: 'Stop all running services' (27 chars), 'Get current status of all services' (34 chars). LLMs cannot determine when to use each tool or distinguish between similar operations (e.g., status vs logs). Per the tool-description pattern, descriptions must explain WHAT, WHEN, and WHAT IS RETURNED.
No output schemas are documented for any tool. LLMs have no guidance on what fields to expect from status(), logs(), or check_ports(). The pattern tool-chain requires that each tool's output include the IDs and references downstream tools need. Without documented return types, composition breaks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error handling guidance. Tools like kill_ports (marked DESTRUCTIVE) and clear_logs (marked WRITE) provide no recovery hints. Per pattern recovery-guide, error responses must tell the LLM what to do next. Example: if kill_ports fails because a port is already in use, should the agent retry, ask the user, or pick a different port?
Destructive operations (kill_ports, clear_logs, stop) lack dry-run or confirmation steps. Per pattern confirmation-request, irreversible operations should support user confirmation. An LLM could accidentally kill production ports or wipe logs without warning.
Parameter descriptions are missing or vague. Example: 'service' in restart/logs is not described, is it the service name string, or a service ID? The logs tool has a 'lines' parameter with default 100, but the description says 'default 100' without explaining the range (min/max). Per pattern constrained-input, all parameters need type, range, and format guidance.
Inconsistent parameter naming. 'start' uses 'services' (array) and 'killPorts' (boolean, camelCase). 'restart' uses 'service' (string). 'logs' uses 'service' (string). 'clear_logs' uses 'service' (string). This inconsistency forces the LLM to reason about which parameter each tool expects, increasing errors. Per naming baseline, use consistent verb_noun naming.
Tool names lack clear verbs. 'status' and 'logs' are nouns, not verbs. Better names: 'get_status', 'get_logs', 'list_logs'. Per naming baseline, 90% of A+ tools start with an action verb. The names 'status' and 'logs' are ambiguous, they could mean 'return status' or 'modify status'.