Loading ToolBench
A local MCP server framework for creating and managing multiple MCP servers with utilities for Python script execution, Excel file searching, and server setup
This MCP server exhibits fundamental quality gaps across naming, descriptions, schemas, and error handling. Both tools have incomplete parameter documentation, lack meaningful descriptions, and expose security vulnerabilities. The run_python tool is particularly dangerous, it accepts arbitrary Python executable paths without validation and allows execution of any script, creating command injection and path traversal risks. Neither tool includes error recovery guidance, output schema documentation, or actionable error messages. The get_python_location tool performs unsafe directory traversal without validation. Overall, this server is not production-ready and would require substantial refactoring before deployment.
gets the location of a Python script to be executed
Run the target python script from a specific location using a specified Python interpreter and return the output from the script.
run_python accepts arbitrary Python executable paths without validation, creating command injection vulnerability. An LLM could pass malicious paths like '/bin/bash -c "rm -rf /"' as the python_exe parameter.
run_python parameter 'python_exe' lacks type definition and validation. The input schema shows only string type with no format, pattern, or constraints. This violates constrained-input pattern and invites hallucinated values.
get_python_location performs unsafe directory traversal via os.walk() without validating script_name. An attacker could pass '../../sensitive_file.py' to access files outside intended scope.
run_python tool description is only 140 characters but lacks critical details: What does it return on failure? How does it handle timeouts? What input formats are safe? Description fails to explain prerequisites or when to use this tool instead of alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
get_python_location description is only 62 characters and answers NONE of the three required questions: What does it do (vague)? When to use it (not explained)? What does it return (not documented)?
Neither tool documents output schema. run_python returns a string (stdout or stderr), but LLMs cannot determine format, structure, or expected content. get_python_location returns a file path string or None, but this is undocumented.
Error handling provides zero recovery guidance. run_python returns 'Script does not exist.' and 'Python interpreter not found', bare error messages that tell LLMs nothing about next steps. Should suggest alternatives or recovery actions.
run_python tool name is generic and ambiguous. 'run_python' could mean run inline code, run a file, compile, interpret, or execute in a REPL. Should be 'execute_python_script' or 'run_python_file' for clarity.
run_python accepts optional python_exe parameter but does not validate it. LLMs could pass version strings ('python3.11'), aliases, or absolute paths that don't exist. Should whitelist valid executables or document constraints.
get_python_location parameter 'script_name' lacks description. Is it a filename, relative path, or fully qualified name? What happens if multiple scripts share the same name? Should it search only public_scripts or the entire filesystem?
run_python returns stderr on failure but stdout on success. No indication to LLM that stderr might contain partial output, warnings, or debug info mixed with errors. Should return structured {status, stdout, stderr, exit_code}.