Skip to main content
Glama
ssdeanx

Node.js Sandbox MCP Server

by ssdeanx

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
FILES_DIRYesDirectory where files created by scripts will be saved (e.g., $HOME/Desktop/sandbox-output)
SANDBOX_CPU_LIMITNoCPU limit for sandbox containers (e.g., '0.75')0.75
SANDBOX_MEMORY_LIMITNoMemory 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

NameDescription
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:

import fs from "fs/promises";
await fs.writeFile("./files/hello.txt", "Hello world!");
console.log("Saved ./files/hello.txt");
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

NameDescription
run-node-js-script

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 7 tools

Disambiguation4/5

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 Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive
ResponsivenessNo issues