Loading ToolBench
MCP server that dynamically exposes Just recipes as tools, allowing execution of recipes defined in a Justfile
Only 1 tool visible in source (cwd). Tool has empty input schema {} and minimal description (11 words). No parameter descriptions. Tool is gated behind ENABLE_DEBUG_TOOL env var, suggesting it's not a primary feature. Dynamic recipe tools are generated at runtime from Justfile parsing, their definitions are not visible in static code, so per-pattern rules cap them at 50. The cwd tool itself fails multiple hard rules: description under 20 chars scores 0-20, empty schema scores 0.
Get the working directory that the MCP server is running in
Descriptions must be 10 - 1024 chars and explain WHAT, WHEN, and WHY. Current description lacks context for LLM selection.
Input schema is empty object {} with no parameters. Even though cwd takes no params, the schema should be explicitly documented as 'no parameters required' in the description.
Dynamic recipe tools (check, build, test, deploy, etc.) are generated at runtime from Justfile parsing. Their definitions are not visible in static source code, only inferred from the loop 'for (const [recipeName, recipe] of Object.entries(recipes))'. Cannot verify parameter descriptions, output schemas, or error handling for these tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
No error handling guidance. If a recipe fails (non-zero exit code), the tool returns 'Process exited with code X' but does not tell the LLM what to do next (retry? ask user? fatal?). Per pattern:recovery-guide, errors must guide the agent's next step.
cwd tool is gated behind ENABLE_DEBUG_TOOL env var and is not a primary feature. It does not align with the server's core purpose (running Just recipes). Including a debug tool in the main tool set dilutes focus and adds noise for LLM tool selection.