Loading ToolBench
This server has only 1 tool (pexpect_tool) with a highly concerning design. While the tool does have a description and input schema visible in the source code, the design violates multiple critical Agentic Tool Patterns. The tool accepts arbitrary Python code execution with access to dangerous system calls (process spawning, signal handling), which is a severe security issue. The description is verbose and includes procedural notes ('DONT WRITE COMMENTS', 'dump with uv --script dependency info') rather than clarifying when/why an LLM should use this tool. The schema is technically present (code: string, timeout: optional int), but the tool's single-responsibility principle is violated, it conflates code execution, session management, and pexpect lifecycle. The timeout handling is complex and buried in implementation details. Error handling is minimal: the tool catches exceptions and returns them as strings, but provides no recovery guidance or actionable next steps for an LLM.
Execute Python code in a pexpect session. Can spawn processes and interact with them. Args: code: Python code to execute. Use 'child' variable to interact with the spawned process. The pexpect library is already imported. Use `pexpect.spawn(...)` to spawn something. timeout: Optional timeout in seconds. If not provided, uses global TIMEOUT (default 10s). DONT WRITE COMMENTS Example: child = pexpect.spawn('lldb ./mytool') child.expect("(lldb)") Returns: The result of the code execution or an error message. When asked to dump out a pexpect transcript, make sure to dump with uv --script dependency info so the user can run it with "uv run session.py"
Tool name 'pexpect_tool' is generic and does not follow verb_noun convention. It should be named with a verb reflecting the actual action (e.g., 'execute_code' or 'run_pexpect_command'). Generic names like 'pexpect_tool' force LLMs to read full documentation to understand intent.
Arbitrary Python code execution is an extreme security risk. The tool accepts a 'code' parameter containing arbitrary Python code and executes it with access to pexpect.spawn(), signal handlers, and process control. There is no input validation, sandboxing, or permission gating. This violates pattern:secret-injection and pattern:tool-gateway. An LLM could be tricked into passing malicious payloads.
Description contains procedural noise ('DONT WRITE COMMENTS', 'dump with uv --script dependency info') instead of clarity on WHEN/WHY to use this tool. Per pattern:tool-description, descriptions should state what the tool does, when to use it instead of alternatives, and what it returns. This description reads like internal notes, not LLM guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Error handling is inadequate. Exceptions are caught and returned as strings (e.g., 'Error: {error}'), but there is no recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next. A TimeoutError or SyntaxError provides no actionable recovery path.
Single tool violates composition principle (pattern:tool). This server conflates arbitrary code execution, pexpect session management, process spawning, and signal handling into one massive tool. It should be split into discrete, composable tools if exposure at all were safe, but arbitrary code execution should not be exposed as an agent tool.
No parameter descriptions for 'code' beyond restating the name. The 'timeout' parameter has a description ('Optional timeout in seconds...'), but 'code' lacks sufficient detail on format, constraints, or what Python syntax is valid. Per pattern:tool-description, every parameter must have a clear description.
Output schema is undocumented. The tool returns a formatted string with RESULT/LOG/BUFFER sections delimited by '---', but there is no formal schema describing this structure. LLMs cannot reliably parse unstructured delimited text. Per pattern:response-shaper, return structured objects with typed fields.
No pagination, batching, or result limits. This tool is designed to execute arbitrary code and interact with spawned processes indefinitely. There is no cap on execution time, output size, or resource consumption, a runaway code snippet could exhaust memory or hang the server.
Global state management (pexpect_session, session_globals) makes this tool non-idempotent. Calling the same code twice with the same input can produce different results depending on prior execution state. Per pattern:idempotent-operation, repeated calls with the same input should produce the same result.