Node Code Sandbox MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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, but run_js and run_js_ephemeral overlap significantly in functionality, both executing JavaScript code with ESModules and file I/O in ./files. The key difference is sandbox persistence versus ephemeral execution, which is clarified in descriptions but could still cause confusion for an agent deciding between them. Other tools like ai_generate, get_dependency_types, and sandbox management tools are clearly differentiated.
The naming conventions are mixed, with some tools using verb_noun patterns (e.g., get_dependency_types, run_js, sandbox_initialize) and others using noun_verb or less structured forms (e.g., ai_generate, sandbox_exec). While still readable, the inconsistency in verb placement and style (like ai_generate vs. run_js) reduces predictability. The sandbox_* tools form a consistent subset, but overall the pattern is not uniform across all tools.
With 7 tools, the count is well-scoped for a Node.js sandbox server, covering code generation, dependency analysis, JavaScript execution (both persistent and ephemeral), and sandbox lifecycle management. Each tool serves a clear purpose, and the number is neither too sparse nor overwhelming, fitting typical server scopes of 3-15 tools effectively.
The tool surface provides good coverage for Node.js sandbox operations, including initialization, execution, and cleanup, with added utilities for AI generation and dependency type checking. Minor gaps exist, such as no direct tool for inspecting or modifying sandbox state beyond execution, but core workflows like running code and managing containers are well-supported, allowing agents to work around limitations.