Run arbitrary JavaScript inside disposable Docker containers and install npm dependencies on the fly.
Server has 7 tools with descriptions present, but critical gaps in schema visibility and parameter documentation. Tool names follow verb_noun convention (sandbox_initialize, sandbox_exec, run_js, etc.), which is good. However, source code provided is incomplete, only package.json, Dockerfile, and partial server.ts shown. Cannot verify actual JSON Schema definitions for input parameters or output structures. Descriptions range from adequate (run_js_ephemeral at ~280 chars) to minimal (sandbox_initialize at ~120 chars). No evidence of parameter-level descriptions, type constraints, or error recovery guidance in visible code. Risk annotations present (WRITE, DESTRUCTIVE, READ_ONLY) but not mapped to tool annotations in schema. Composition is reasonable, tools are single-purpose (initialize, exec, stop, run, search, get_types), but chaining dependencies not documented.
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"); ```
Execute one or more shell commands inside a running sandbox container. Requires a sandbox initialized beforehand.
No input schemas visible in provided source code. Cannot verify parameter types, constraints, enums, or descriptions. All 7 tools scored 0 for schema dimension.
Tool descriptions lack parameter-level guidance. E.g., run_js mentions 'install npm dependencies' and './files directory' but does not document what parameters control this behavior or what format they expect.
No error handling or recovery guidance documented. Tools like sandbox_initialize and sandbox_exec can fail (Docker unavailable, container crash, command timeout) but descriptions do not explain what to do on failure or how to retry.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | <=2025-11-25 | v2 |
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.
Search for npm packages by a search term and get their name, description, and a README snippet.
Risk annotations (WRITE, DESTRUCTIVE) present in metadata but not mapped to tool schema annotations (destructiveHint, idempotentHint). LLM cannot infer side effects from schema alone.
Output schemas not documented. Tools return results (e.g., run_js_ephemeral returns execution output, search_npm_packages returns package list) but response structure, field names, and types are not specified.