Loading ToolBench
A Model Context Protocol (MCP) server for executing Nushell scripts
The server defines a single tool 'exec' with a properly declared input schema using schemars and Rust structs. The tool has a comprehensive, detailed description that includes execution patterns and Nushell syntax guidance, well above the baseline of 194 chars (this description is ~1,200 chars). However, the description is excessively long and includes implementation guidance that belongs in error messages or separate docs, not the tool description itself. Parameter types are present (string, integer) with defaults and descriptions. The output is returned as JSON text content rather than structured objects with documented schema. Error handling provides timeout guidance but lacks categorization (retryable vs fatal). No security annotations or input validation guidance visible. Tool naming 'exec' is generic and does not clearly convey 'execute nushell script', a more specific verb_noun pattern like 'exec_nushell' or 'run_nushell_script' would be clearer.
Executes a nushell script and returns stdout, stderr, and exit code. EXECUTION PATTERN - CRITICAL: Execute ONE command at a time that produces meaningful output. For complex tasks, break into sequential single commands like a human operator would. This allows: - Seeing intermediate results before proceeding - Easier error diagnosis and recovery - Step-by-step validation of progress AVOID: Long multi-step scripts that could fail midway PREFER: Single commands with clear output, then assess and continue IMPORTANT NUSHELL SYNTAX DIFFERENCES FROM POSIX: Line Continuation: - NO trailing backslashes (\). Use parentheses () for multi-line pipelines - Example: (ls | where size > 1MB | get name) Output/Printing: - DON'T use 'echo' - it doesn't work like POSIX echo - Use 'print' for side-effect output: print 'hello world' - Use string literals for return values: 'return value' - Use pipelines for processing: 'data' | filter | transform Common Patterns: - Filter: ls | where size > 1MB - Transform: ls | get name - Variables: let var = 'value' - Return from pipeline: 'result' (not echo 'result') Data Types: - Nushell is structured data focused - Commands return tables/records, not just text - Use 'to csv' to convert structured data for LLM consumption - Use 'to text' for plain text output
Tool name 'exec' is generic and ambiguous. Does not follow verb_noun pattern clearly. 'exec' alone does not tell LLMs this specifically runs Nushell scripts, they might confuse it with shell exec, command execution, etc. Should be 'exec_nushell', 'run_nushell', or 'run_nushell_script'.
Description is excessively long (~1,200 chars, well beyond the 10 - 1024 baseline). While comprehensive, it mixes execution guidance (AVOID long scripts, PREFER single commands) and Nushell syntax teaching into the tool description. This belongs in deployment docs, error messages, or agent instructions, not in the tool definition, which should focus on WHAT the tool does and WHEN to use it. Compress to ~150 - 200 chars and move implementation guidance to separate docs.
Output is returned as stringified JSON in a text Content block, not as a structured object with a documented schema. LLMs must parse the JSON string to extract stdout, stderr, and exit_code. Response schema is not documented, LLMs cannot infer the structure of the return value. Should return structured CallToolResult with typed fields or document the output schema explicitly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | 2024-11-05+ | v1 |
Error messages are generic ('Command execution failed', 'Command timed out'). They do not guide LLMs on recovery actions. Timeout error message includes guidance ('Consider breaking down complex scripts into smaller steps'), which is good, but other errors are not actionable. Should add suggestions: 'Command execution failed: {error_details}. Verify the Nushell syntax and try a simpler command.'
No tool annotations present. The 'exec' tool is irreversible (script execution has side effects) and should be marked with destructiveHint=true. This tells agents and clients to exercise caution. No idempotent, readOnly, or destructive hints visible.
No input validation guidance in parameter descriptions. The 'script' parameter accepts any string. Should include constraints: 'Must be a valid Nushell script. Avoid commands with unbounded output or infinite loops.' The 'timeout_seconds' parameter has a default (30) but no documented range or constraints (e.g., min=1, max=300).