Node.js Sandbox MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FILES_DIR | Yes | Directory where files created by scripts will be saved (e.g., $HOME/Desktop/sandbox-output) | |
| SANDBOX_CPU_LIMIT | No | CPU limit for sandbox containers (e.g., '0.75') | 0.75 |
| SANDBOX_MEMORY_LIMIT | No | Memory limit for sandbox containers (e.g., '512m') | 512m |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sandbox_initializeB | Start a new isolated Docker container running Node.js. Used to set up a sandbox session for multiple commands and scripts. |
| sandbox_execB | Execute one or more shell commands inside a running sandbox container. Requires a sandbox initialized beforehand. |
| run_jsA | 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. |
| sandbox_stopA | Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize. |
| run_js_ephemeralA | 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: |
| get_dependency_typesB | 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. |
| ai_generateC | Generate text using Google Gemini. Provide a prompt and optional model name. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| run-node-js-script |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools have distinct purposes: ai_generate is for text generation, get_dependency_types is for type inspection, and the sandbox tools (initialize, exec, stop) form a clear lifecycle. However, run_js and run_js_ephemeral overlap significantly in functionality—both run JavaScript code with dependencies—which could cause confusion despite differences in persistence and cleanup.
Naming is mixed: ai_generate and get_dependency_types use snake_case, while sandbox_initialize, sandbox_exec, and sandbox_stop use a consistent 'sandbox_' prefix with snake_case. However, run_js and run_js_ephemeral deviate with a 'run_' prefix and lack the 'sandbox_' pattern, creating inconsistency. The verb styles vary (e.g., 'get', 'run', 'sandbox_exec'), reducing predictability.
With 7 tools, the count is well-scoped for a Node.js sandbox server. It covers core areas: AI text generation, dependency type inspection, JavaScript execution (both persistent and ephemeral), and sandbox management (initialize, execute commands, stop). Each tool earns its place without feeling bloated or insufficient.
The toolset provides strong coverage for Node.js sandbox operations, including sandbox lifecycle management and code execution. A minor gap exists: there's no tool for inspecting or managing files within the sandbox beyond the implied './files' directory usage, which agents might need to work around. Otherwise, core workflows are well-supported.