Loading ToolBench
An embeddable Python runtime where AI agents call tools as code — MCP servers, APIs and shells as native Python objects.
Parselbox is an embeddable Python sandbox runtime that exposes 9 tools, but quality is significantly hampered by missing input schemas, incomplete descriptions, and lack of output documentation. Most tool definitions are inferred from sparse code references rather than explicit MCP registration. Naming is reasonable (verb-driven), but parameter documentation and schema formalization are nearly absent. The server positions itself as a meta-sandbox for introspection and code execution, which is conceptually valuable, but the implementation lacks rigor in tool definition and error handling. Only 2 of 9 tools have documented input schemas visible in the source. None have output schemas. Descriptions are present but generic and below the 50-200 character optimal range.
Execute bash commands in the sandbox
Render HTML as a widget in the conversation
Execute Python code in the sandbox
Return a comprehensive guide on how to use the Parselbox sandbox.
Get sandbox environment information.
Get detailed signatures and documentation for tools.
Generate a condensed summary of large or deeply nested data.
Missing input schemas for 7 of 9 tools. Only 'search' and 'write_file' have visible parameter definitions. Tools like 'help', 'info', 'preview', 'display' and 'bash' lack formal JSON Schema documentation, making it impossible for LLMs to understand valid input structure.
No output schemas documented for any tool. LLMs cannot predict return types, fields, or structure. For example, 'search' returns a dict structure but the shape is not formally declared. 'info' returns environment data but fields are undocumented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Search for tools across all namespaces by name, description, or parameter.
Write file from host to sandbox
Parameter descriptions are missing or vague. 'search' accepts 'pattern' with description 'Regex pattern...' (acceptable), but 'inspect' accepts 'tool_names' described as 'Tool reference or list of references' without clarifying the namespace.tool syntax, expected format, or behavior when a tool is not found.
Irreversible operations ('execute_code', 'bash', 'write_file') lack confirmation/dry-run support and do not document rollback behavior. An LLM could call 'bash rm -rf /' with no guardrail, and the tool description does not warn of this risk or suggest confirmation mechanisms.
Error handling is not documented. No tool description specifies what errors can occur, when they are retryable, or what the LLM should do next. For example, 'inspect' may fail if a tool_name does not exist, the response should guide the LLM to call 'search' first.
Tool 'help' is generic and does not explain when to call it. 'Return a comprehensive guide' could mean the tool returns a large block of text, LLMs cannot reason about whether this is appropriate without understanding output size and optimal use cases.
Tool definitions are inferred from scattered code files (examples/typescript-client/server.ts, parselbox/main.py, etc.) rather than seen in a single authoritative tool registration. This makes it unclear whether these are the canonical definitions or just usage examples.
'write_file' accepts 'path' and 'contents' but does not specify path constraints (absolute vs relative, sandbox boundaries, forbidden directories). LLMs could attempt to write outside the sandbox, and the tool should validate and reject such attempts with clear guidance.