Loading ToolBench
MCP server for executing Python code with advanced monitoring and safety features
Mixed quality across 5 tools. All tools have descriptions and basic schemas, but several critical gaps emerge: (1) execute_python and install_packages accept destructive/write operations yet lack confirmation/dry-run patterns; (2) parameter descriptions vary in completeness, some are detailed (e.g., install_packages with version examples), others are minimal; (3) output schemas are not documented anywhere in the source, LLMs cannot know what fields to expect from tool responses; (4) no error handling guidance visible (pattern:recovery-guide), responses appear to return raw errors; (5) analyze_code tool is READ_ONLY but its output structure is undocumented; (6) tool names are adequate (verb_noun form: execute_, install_, get_, health_check, analyze_) but compositions could be improved, execute_python should reject dangerous patterns or require analyze_code first. Average per-tool score: 58.
Analyze Python code for security issues, style violations, and complexity metrics. Performs: 1. Security analysis (detects dangerous patterns) 2. Style analysis (PEP 8 compliance check) 3. Complexity metrics (cyclomatic complexity, maintainability index) Useful for code review and quality assurance before execution.
Execute Python code in a secure, isolated environment with configurable resource limits. Features: - Automatic virtual environment management - Resource monitoring (memory, CPU) - Input/output stream handling - Error handling and timeout protection - Support for both inline code and existing script files Example workflow: 1. First install required packages using install_packages 2. Write your Python code with proper error handling 3. Optionally prepare input data as string array 4. Call execute_python with your code or scriptPath 5. Check the response for output or errors 6. For long-running scripts, monitor health_check Example usage with inline code: { "code": "import numpy as np\ntry:\n data = np.random.rand(3,3)\n print(data)\nexcept Exception as e:\n print(f'Error: {e}')", "inputData": ["optional", "input", "strings"] } Example usage with a script file: { "scriptPath": "/path/to/your/script.py", "inputData": ["optional", "input", "strings"] } Common workflows: 1. Data processing: - Install numpy and pandas - Load and process data - Output results 2. Machine learning: - Install scikit-learn - Train model - Make predictions 3. Web scraping: - Install requests and beautifulsoup4 - Fetch and parse content - Extract data
Get execution metrics and server health statistics. Returns aggregated metrics for all Python executions including: - Total number of executions - Success/error rates - Average execution times - Memory usage statistics - Server uptime - Recent execution history Useful for: 1. Monitoring server performance 2. Identifying bottlenecks 3. Resource usage analysis 4. Health checking
No output schemas documented for any tool. LLMs cannot predict response structure, field types, or how to extract data for downstream tool calls. This violates pattern:tool (Document the output schema) and pattern:response-shaper (Return structured objects with typed fields).
execute_python marked DESTRUCTIVE with arbitrary code execution capability, yet no dry-run, confirmation, or permission-gate pattern. Agents can execute malicious or unintended code without review.
install_packages marked WRITE but no rollback or compensation mechanism documented. If package installation partially fails or conflicts, agent has no way to undo or recover.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Perform a health check of the Python executor environment. Verifies: - Python installation and version - Virtual environment status - System resources (disk space, memory) - Pre-installed package availability - Configuration validity Returns detailed status information for diagnostics.
Install Python packages in the configured virtual environment using pip. Features: - Install single or multiple packages - Support for specific version specifications - Automatic virtual environment activation - Dependency resolution and conflict detection - Package validation before installation Example usage for single package: { "packages": "requests" } Example usage for multiple packages: { "packages": ["numpy", "pandas", "matplotlib"] } Example usage with version specifications: { "packages": ["numpy==1.21.0", "pandas>=1.3.0", "scipy"] } Common package installation patterns: 1. Data science stack: - numpy, pandas, matplotlib, scikit-learn 2. Web development: - requests, beautifulsoup4, flask, django 3. Data processing: - pandas, openpyxl, csvkit 4. Scientific computing: - scipy, sympy, statsmodels
Descriptions for execute_python and install_packages contain example code and package names (e.g., 'numpy==1.21.0', 'import numpy as np'). LLMs tend to reuse example values literally in real calls, causing failures or unexpected behavior.
No error handling guidance visible. If code execution fails, package install conflicts, or a check fails, response appears to return raw errors. No recovery patterns (pattern:recovery-guide), LLMs receive no next-step guidance.
Parameter descriptions for get_metrics and health_check are thin (70-110 chars). Missing details on format constraints (e.g., are timestamp fields ISO 8601 or Unix epoch?), ranges, and interpretation for LLM decision-making.
Tool composition gap: execute_python could receive unsafe code (SQL injection, command injection, path traversal) without validation. analyze_code detects some issues but is a separate tool, no composition guarantee that analyze_code is called first.
Pagination and result limits not addressed. get_metrics mentions 'recent execution history' with no limit, count, or pagination params. Large histories could bloat response and exhaust context window.