Loading ToolBench
MCP server for a guarded xonsh shell and cwd-scoped filesystem tools
Tree Climber MCP has 4 tools with visible schemas and descriptions. Naming follows verb_noun convention (command_line_interface_tool, list_directory, read_file, write_file), though command_line_interface_tool is verbose. All tools have descriptions (range: 57 - 95 chars, within the productive 10 - 1024 range). Input schemas are properly defined with JSON Schema, but parameter descriptions are minimal, most lack guidance on constraints, format expectations, or when to use them. The server lacks error handling guidance, tool annotations (readOnlyHint/destructiveHint), output schema documentation, and structured recovery paths. STDIO transport hard-caps the protocol readiness score at 50, which significantly limits overall capability. The filesystem tools (read_file, write_file, list_directory) lack documentation of output fields and structure. Security controls are present (filesystem_root, allow_all_paths flags) but not exposed as tool-level metadata or permission annotations.
Runs a provided bash command in an xonsh shell instance.
Lists the files and subdirectories in the specified directory.
Reads the contents of a file.
Writes content to a file. Overwrites existing files.
Parameter descriptions lack actionable constraints and format guidance. E.g., 'bash_command' has no note on how the shell is restricted, what characters are banned, or what happens if the command fails. LLMs cannot infer these constraints from names alone.
Output schemas are not documented. Clients calling read_file, list_directory, or write_file cannot know what fields to expect in the response. This forces the LLM to guess and blocks downstream tool chaining.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) despite clear risk profiles. command_line_interface_tool is IRREVERSIBLE; write_file is WRITE; read_file and list_directory are READ_ONLY. Annotations let the LLM know which operations are safe to retry.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error handling provides no recovery guidance. If command_line_interface_tool fails (timeout, permission denied, etc.), the LLM has no way to know whether to retry, adjust parameters, or abort. No categorization of errors as retryable vs. fatal.
command_line_interface_tool name is verbose and does not follow clean verb_noun convention. 'run_command' or 'execute_bash' would be clearer and shorter (pattern baseline: 18 chars avg; this is 27 chars).
Banned command patterns are defined in security.py but not exposed to the LLM or documented in tool descriptions. The agent has no way to know which commands will be rejected until runtime.
list_directory parameter 'path' defaults to current directory but the description does not state this default. LLMs cannot infer defaults from names alone; explicit documentation is required.
Timeout parameter in command_line_interface_tool has explicit bounds (1 - 60 seconds) but no guidance on when to increase it. What commands typically require longer timeouts? No examples or decision heuristics.