Loading ToolBench
A configuration-driven MCP server for running developer commands and tools
This server has fundamental definition quality issues. Five tools are declared, but tool definitions are dynamically generated from config files, making explicit schema validation impossible in source code. Of the visible tools: (1) dynamic_tools_from_config lacks input schema entirely and has a generic description; (2) _start, _status, _stop tools have empty required parameters and no descriptions of what parameters they accept; (3) _logs has one parameter 'lines' with a description, but the tool itself lacks a meaningful description. Parameter descriptions are minimal or absent for most tools. No output schemas are documented anywhere. Error handling exists at the executor level but is not reflected in tool definitions. The naming convention uses underscores for daemon lifecycle tools, which is acceptable, but the base tool 'dynamic_tools_from_config' is poorly named, it does not perform an action; it declares a pattern. This violates the verb-noun naming rule.
{tool.description from config}
Get recent logs from {tool.name} (last 50 lines)
Start the {tool.name} daemon
Get status and recent output from {tool.name}
Stop the {tool.name} daemon
Tool definitions are dynamically generated from config files; no explicit input schemas are visible in source code for the templated tools. The schema score for _start, _status, _stop cannot exceed 0 because no input schema properties are visible beyond empty required arrays.
Tool 'dynamic_tools_from_config' does not follow verb-noun naming. It describes a pattern, not an action. The tool name should reflect what calling it accomplishes, not that tools are loaded from config.
Most tool descriptions are generic or missing (12-30 chars). '_start' says 'Start a configured daemon process' (35 chars), which lacks context about what happens when called, whether it is idempotent, and what return value to expect. Descriptions should be 50-200 chars and explain WHAT, WHEN, and consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
No output schemas are documented for any tool. LLMs cannot plan downstream calls or extract data without knowing what fields to expect. Return structure is inferred only from ToolExecutor.ts code (success + output fields), but this is not declared in tool definitions.
Parameter descriptions are missing or trivial. The '_logs' tool accepts 'lines' (number), which has a description, but other tools accept parameters via args object (toolName.replace logic) without formal schema or descriptions. This forces LLMs to guess at parameter structure.
Error handling in source code (ToolExecutor.ts) returns generic error messages without recovery guidance. E.g., 'Configuration not found for tool: {toolName}' does not tell LLM what to do next. Should suggest alternatives or valid tool names.