Loading ToolBench
A safe venv controller for coding agents: create/select a project venv and run restricted pip operations through that venv's Python, with persistence + audit.
The server defines 5 tools with clear, verb-based names and mostly complete schemas. However, descriptions lack LLM-optimization guidance (many exceed 200 chars and include implementation details), parameters lack granular descriptions in some cases, and output schemas are not formally documented. Error handling is present but minimal. This is a solid mid-tier implementation, well above F, but with room for production hardening.
Create a venv inside the active workspace (default: .venv) and set it active.
Use an existing venv inside the active workspace and set it active.
Write pinned requirements from the active venv to a file in the workspace.
Run a restricted pip action inside the active venv. Parameters: - action: install | uninstall | list | show | check - packages: list of packages/specs (e.g. ["requests", "numpy==2.1.0"]) - options: allowlisted pip options only (see server policy) - confirm: required for uninstall (safety)
Select the project/workspace to manage. - 'path' can be a repo root or any subdirectory inside a repo. - The server will auto-find the workspace root by walking up to pyproject.toml or .git. - All future operations (env_create/pip/freeze) are sandboxed to this workspace.
Output schemas are not formally documented. Tools return dict with 'ok', 'workspace_root', 'env_dir', 'python_executable', etc., but LLMs cannot see these fields in advance. This violates the pattern:tool requirement and forces LLMs to infer structure from example responses.
Tool descriptions exceed LLM-optimized length. pip (237 chars) and env_create/env_use (81 chars) descriptions are too terse or too verbose. Best practice is 50-200 chars to balance context without wasting tokens.
Parameter descriptions are incomplete or missing. 'options' parameter in pip tool is described as 'allowlisted pip options only' but does not explain which options are allowed, what the allowlist is, or why. LLMs cannot infer the constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Error handling is minimal. Tools raise ValueError or generic exceptions, but error messages do not guide recovery. E.g., 'No active env in this workspace' is clear, but lacks actionable next steps ('Call env_create() or env_use() first'). Missing pattern:recovery-guide.
pip tool accepts 'options' parameter without documenting the allowlist. Descriptions state 'allowlisted pip options only (see server policy)' but the policy is not visible in the schema or description. LLMs cannot verify their choices before calling the tool.
No confirmation pattern for destructive operations. freeze and pip uninstall can overwrite files or remove packages, but lack a dry-run, confirm, or preview step. pip uninstall requires confirm=true (good), but freeze does not ask permission before overwriting requirements.txt.
workspace_use tool allows arbitrary path input without validation against workspace boundaries. While resolve_in_workspace likely prevents directory traversal, the tool description does not mention security constraints. An LLM could attempt to set workspace to / or other unsafe paths.
No pagination or batching for pip list / show results. If an agent calls pip list on a large venv, stdout could exceed MAX_STDOUT_CHARS (80,000) without truncation guidance. LLMs may not understand why output is incomplete.