Loading ToolBench
Run arbitrary JavaScript inside disposable Docker containers and install npm dependencies on the fly.
This MCP server exposes 7 tools for sandboxed Node.js execution. While tool names follow verb_noun patterns and descriptions are present, multiple critical quality gaps significantly reduce production readiness. Three tools (sandbox_initialize, sandbox_exec, run_js) lack visible input schemas in the provided source, preventing schema validation. Descriptions vary widely in quality, some are detailed (run_js_ephemeral with code examples), others are generic. Parameter descriptions are largely absent from the visible schema definitions. Error handling guidance is missing from descriptions. The server is STDIO-only, which is a hard transport limitation. Output schemas are undocumented. Overall, this is a fair but incomplete implementation typical of community tools.
Generate text using Google Gemini. Provide a prompt and optional model name.
Given an array of npm package names (and optional versions), fetch whether each package ships its own TypeScript definitions or has a corresponding @types/… package, and return the raw .d.ts text. Useful whenwhen you're about to run a Node.js script against an unfamiliar dependency and want to inspect what APIs and types it exposes.
Install npm dependencies and run JavaScript code inside a running sandbox container. After running, you must manually stop the sandbox to free resources. The code must be valid ESModules (import/export syntax). Best for complex workflows where you want to reuse the environment across multiple executions. When reading and writing from the Node.js processes, you always need to read from and write to the "./files" directory to ensure persistence on the mounted volume.
Run a JavaScript snippet in a temporary disposable container with optional npm dependencies, then automatically clean up. The code must be valid ESModules (import/export syntax). Ideal for simple one-shot executions without maintaining a sandbox or managing cleanup manually. When reading and writing from the Node.js processes, you always need to read from and write to the "./files" directory to ensure persistence on the mounted volume. This includes images (e.g., PNG, JPEG) and other files (e.g., text, JSON, binaries). Example: ```js import fs from "fs/promises"; await fs.writeFile("./files/hello.txt", "Hello world!"); console.log("Saved ./files/hello.txt"); ```
No visible input schemas for any of 7 tools. Tool definitions reference argSchema imports (initializeSchema, execSchema, runJsSchema, etc.) but the actual schema objects are not shown in the provided source code. Cannot verify parameter types, required fields, constraints, or descriptions.
Output schemas are not documented. The server returns responses from tools (container logs, file contents, TypeScript definitions, etc.) but the response structure is never formally specified. LLMs cannot reason about downstream tool composition without knowing what fields to expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 34 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Execute one or more shell commands inside a running sandbox container. Requires a sandbox initialized beforehand.
Start a new isolated Docker container running Node.js. Used to set up a sandbox session for multiple commands and scripts.
Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize.
Error handling descriptions missing. Tool descriptions state what the tool does but not what errors can occur, how to recover, or whether they are retryable. Example: sandbox_exec says 'Requires a sandbox initialized beforehand' but does not say what happens if you call it without initializing (does it fail? timeout? hang?).
Composition risk: ai_generate tool (Generate text using Google Gemini) appears disconnected from the sandbox environment. It accepts 'a prompt and optional model name' but does not explain when/why an agent would call it in the context of code execution. Is this meant to generate code? Tests? Documentation? The purpose is ambiguous.
Parameter naming/typing not visible. Tools reference schema imports but full parameter definitions (required, type, description, constraints, enum) are not shown. Cannot verify if parameters accept human-friendly names (e.g., user_email) or only opaque IDs, or if constraints are enforced.
Secrets management unclear. ai_generate description mentions 'Google Gemini' but does not explain how API keys are injected. The env-file reference in package.json suggests .env is used, but tool descriptions should NOT assume server-side setup, they must explicitly state 'Credentials are injected server-side via GOOGLE_GEMINI_API_KEY' to assure users secrets are safe.
Idempotency not declared. sandbox_initialize, sandbox_exec, and run_js modify container state and likely have side effects. Descriptions should state whether repeated calls with the same parameters are safe (idempotent) or will have compounding effects. This matters for agent retry behavior.