Skip to main content
Glama
mozicim

Node Code Sandbox MCP

by mozicim

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

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.5/5.0

Scored across 7 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive
ResponsivenessNo issues