This MCP server provides 8 bash-related tools with basic definitions but significant quality gaps. All tools have schema definitions visible in the code (pkg/model/tools.go), but the descriptions are extremely brief and lack LLM-optimized context. The schema structure is present but minimal, most parameters lack detailed constraints, ranges, or guidance on valid values. No output schemas are documented. Error handling descriptions are absent. The tools themselves are well-namespaced (bash_*) and follow verb-noun conventions, but descriptions do not explain WHEN to use each tool or what it returns. Critical security risk: bash_execute and bash_script are irreversible operations that lack any confirmation or dry-run support, and the descriptions do not warn about this. Parameter descriptions are generic and under 50 characters, well below the 72-char baseline for A+ tools.

• Expand all descriptions to 150-250 characters. State WHAT each tool does, WHEN to use it (e.g. 'Use to find the full path of a command in PATH'), and WHAT it returns (e.g. 'Returns the absolute path as a string, or an error if not found').
• For bash_execute and bash_script, add explicit warnings: 'IRREVERSIBLE: Executes arbitrary bash code. Cannot be undone. Validate input carefully.' Include a dry_run parameter or confirmation step pattern.
• Document output schemas for every tool. E.g., bash_history returns an array of strings, bash_which returns a string (path or error), bash_env returns a map of environment variables.
• Add parameter constraints to bash_execute and bash_script: explain what happens on timeout, what exit codes mean, whether stderr is captured, and any forbidden command patterns (e.g. 'Does not support interactive prompts').
• Add error handling guidance: 'Returns isError=true for non-zero exit codes. stderr is included in the error message. Agent should examine the error and retry with corrected syntax.'
• Implement input validation at the server level to reject dangerous patterns (e.g. commands containing credentials, rm -rf, > /dev/null redirects). Return clear errors explaining why the command was blocked.
• Consider splitting bash_execute into bash_execute_readonly and bash_execute_dangerous to help LLMs reason about side effects.
• Add a bash_execute_dry_run tool that parses the command and returns an analysis (e.g. 'Would delete 5 files from /home/user/data') without actually executing. Agents can call this to preview before committing.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry