Loading ToolBench
An MCP client that acts as an intelligent agent orchestrating multiple MCP servers (bash, file I/O, Chrome, etc.) via an LLM. It manages tool discovery, invocation, response cleaning, and maintains conversation history.
Lazy_Terminal exhibits critical definition quality failures across all tools. Tool names lack clear verb prefixes, descriptions are inadequate or in foreign languages, input schemas are present but lack critical parameter-level descriptions, and output schemas are completely undocumented. The server integrates with external MCP servers but does not itself provide well-structured tool definitions for production agent use. Schema validation is present but insufficient; parameter descriptions are sparse or absent. This server would require substantial refactoring to meet baseline agent tool standards.
读写本地文件的服务
Greets the user with the given name
Launch Chrome to open a specific URL.
[Generate a valid bash script] that solves the user's task. - Do not use 'sudo' or any root-only commands; - Use heredoc (cat <<EOF > file) to write source code if needed. - Return your response as plain bash commands, separated by newlines. - The output should be directly executable in a non-root Unix environment. example: open an application, write code, find files...
Foreign-language description (Chinese) on file_io tool: '读写本地文件的服务'. Descriptions must be in English and LLM-optimized. This prevents non-Chinese-speaking agents from understanding when/why to call the tool.
Ambiguous tool name 'file_io' lacks action verb. Should be 'read_file' + 'write_file' (split by operation) or 'manage_file'. 'file_io' does not convey what action the tool performs, forcing LLM guessing.
run_bash_script description is instructions to the LLM, not a tool description. Should state: 'Execute arbitrary bash commands in a non-root Unix environment.' Current description reads as a prompt injection risk and wastes tokens on usage guidance that belongs in the system prompt.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured results. Baseline requires documented return types for all tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Parameter descriptions missing or trivial. 'commands' in run_bash_script has no description; 'action' in file_io has Chinese description; 'content' in file_io has no conditional logic documented (only required when action='write').
Tool name 'run_bash_script' is passive/generic. Better: 'execute_bash' or 'execute_shell_command'. Current name does not clearly signal that this is a destructive command-execution tool.
file_io 'action' parameter should be an enum but has no enum constraint visible in schema. Enum ['read', 'write'] must be formally declared in JSON Schema to prevent hallucinated values.
No error handling guidance. If file_io fails on 'path' traversal attack (e.g., '../../secret'), LLM receives only a failure signal with no recovery path. Error responses must guide LLM on retry vs. clarification vs. failure.
run_bash_script marked DESTRUCTIVE but description does not explicitly state it modifies the system. Destructive tools must have descriptions stating: 'WARNING: This tool modifies system state. Commands are executed immediately and cannot be undone.'
No permission gates or security scopes documented. run_bash_script can execute arbitrary commands; file_io can read/write any path. No description of required permissions (e.g., 'write:filesystem', 'execute:shell') or scope limits.