Skip to main content
Glama
ssdeanx

Node.js Sandbox MCP Server

by ssdeanx
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

🐢🚀 Node.js Sandbox MCP Server

Node.js server implementing the Model Context Protocol (MCP) for running arbitrary JavaScript in ephemeral Docker containers with on‑the‑fly npm dependency installation.

Website Preview

👉 Look at the official website

Features

  • Start and manage isolated Node.js sandbox containers

  • Execute arbitrary shell commands inside containers

  • Install specified npm dependencies per job

  • Run ES module JavaScript snippets and capture stdout

  • Tear down containers cleanly

  • Detached Mode: Keep the container alive after script execution (e.g. for long-running servers)

Note: Containers run with controlled CPU/memory limits.

Related MCP server: MCP QuickJS Runner

Explore Cool Use Cases

If you want ideas for cool and powerful ways to use this library, check out the use cases section on the website It contains a curated list of prompts, examples, and creative experiments you can try with the Node.js Sandbox MCP Server.

⚠️ Prerequisites

To use this MCP server, Docker must be installed and running on your machine.

Tip: Pre-pull any Docker images you'll need to avoid delays during first execution.

Example recommended images:

  • node:lts-slim

  • mcr.microsoft.com/playwright:v1.52.0-noble

  • alfonsograziano/node-chartjs-canvas:latest

Getting started

In order to get started with this MCP server, first of all you need to connect it to a client (for example Claude Desktop).

Once it's running, you can test that it's fully working with a couple of test prompts:

  • Validate that the tool can run:

    Create and run a JS script with a console.log("Hello World")

    This should run a console.log and in the tool response you should be able to see Hello World.

  • Validate that you can install dependencies and save files

    Create and run a JS script that generates a QR code for the URL `https://nodejs.org/en`, and save it as `qrcode.png` **Tip:** Use the `qrcode` package.

    This should create a file in your mounted directory (for example the Desktop) called "qrcode.png"

Usage with Claude Desktop

Add this to your claude_desktop_config.json: You can follow the Official Guide to install this MCP server

{
  "mcpServers": {
    "js-sandbox": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-v",
        "/var/run/docker.sock:/var/run/docker.sock",
        "-v",
        "$HOME/Desktop/sandbox-output:/root",
        "-e",
        "FILES_DIR=$HOME/Desktop/sandbox-output",
        "-e",
        "SANDBOX_MEMORY_LIMIT=512m", // optional
        "-e",
        "SANDBOX_CPU_LIMIT=0.75", // optional
        "alfonsograziano/node-code-sandbox-mcp"
      ]
    }
  }
}

or with NPX:

{
  "mcpServers": {
    "node-code-sandbox-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "node-code-sandbox-mcp"],
      "env": {
        "FILES_DIR": "/Users/alfonsograziano/Desktop/node-sandbox",
        "SANDBOX_MEMORY_LIMIT": "512m", // optional
        "SANDBOX_CPU_LIMIT": "0.75" // optional
      }
    }
  }
}

Note: Ensure your working directory points to the built server, and Docker is installed/running.

Docker

Run the server in a container (mount Docker socket if needed), and pass through your desired host output directory as an env var:

# Build locally if necessary
# docker build -t alfonsograziano/node-code-sandbox-mcp .

docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$HOME/Desktop/sandbox-output":"/root" \
  -e FILES_DIR="$HOME/Desktop/sandbox-output" \
  -e SANDBOX_MEMORY_LIMIT="512m" \
  -e SANDBOX_CPU_LIMIT="0.5" \
  alfonsograziano/node-code-sandbox-mcp stdio

This bind-mounts your host folder into the container at the same absolute path and makes FILES_DIR available inside the MCP server.

Usage with VS Code

Quick install buttons (VS Code & Insiders):

Install js-sandbox-mcp (NPX) Install js-sandbox-mcp (Docker)

Manual configuration: Add to your VS Code settings.json or .vscode/mcp.json:

"mcp": {
    "servers": {
        "js-sandbox": {
            "command": "docker",
            "args": [
                "run",
                "-i",
                "--rm",
                "-v", "/var/run/docker.sock:/var/run/docker.sock",
                "-v", "$HOME/Desktop/sandbox-output:/root",
                "-e", "FILES_DIR=$HOME/Desktop/sandbox-output",
                "-e", "SANDBOX_MEMORY_LIMIT=512m",
                "-e", "SANDBOX_CPU_LIMIT=1",
                "alfonsograziano/node-code-sandbox-mcp"
              ]
        }
    }
}

API

Tools

run_js_ephemeral

Run a one-off JS script in a brand-new disposable container.

Inputs:

  • image (string, optional): Docker image to use (default: node:lts-slim).

  • code (string, required): JavaScript source to execute.

  • dependencies (array of { name, version }, optional): NPM packages and versions to install (default: []).

Behavior:

  1. Creates a fresh container.

  2. Writes your index.js and a minimal package.json.

  3. Installs the specified dependencies.

  4. Executes the script.

  5. Tears down (removes) the container.

  6. Returns the captured stdout.

  7. If your code saves any files in the current directory, these files will be returned automatically.

    • Images (e.g., PNG, JPEG) are returned as image content.

    • Other files (e.g., .txt, .json) are returned as resource content.

    • Note: the file saving feature is currently available only in the ephemeral tool.

Tip: To get files back, simply save them during your script execution.

Example Call:

{
  "name": "run_js_ephemeral",
  "arguments": {
    "image": "node:lts-slim",
    "code": "console.log('One-shot run!');",
    "dependencies": [{ "name": "lodash", "version": "^4.17.21" }],
  },
}

Example to save a file:

import fs from 'fs/promises';

await fs.writeFile('hello.txt', 'Hello world!');
console.log('Saved hello.txt');

This will return the console output and the hello.txt file.

sandbox_initialize

Start a fresh sandbox container.

  • Input:

    • image (string, optional, default: node:lts-slim): Docker image for the sandbox

    • port (number, optional): If set, maps this container port to the host

  • Output: Container ID string

sandbox_exec

Run shell commands inside the running sandbox.

  • Input:

    • container_id (string): ID from sandbox_initialize

    • commands (string[]): Array of shell commands to execute

  • Output: Combined stdout of each command

run_js

Install npm dependencies and execute JavaScript code.

  • Input:

    • container_id (string): ID from sandbox_initialize

    • code (string): JS source to run (ES modules supported)

    • dependencies (array of { name, version }, optional, default: []): npm package names → semver versions

    • listenOnPort (number, optional): If set, leaves the process running and exposes this port to the host (Detached Mode)

  • Behavior:

    1. Creates a temp workspace inside the container

    2. Writes index.js and a minimal package.json

    3. Runs npm install --omit=dev --ignore-scripts --no-audit --loglevel=error

    4. Executes node index.js and captures stdout, or leaves process running in background if listenOnPort is set

    5. Cleans up workspace unless running in detached mode

  • Output: Script stdout or background execution notice

sandbox_stop

Terminate and remove the sandbox container.

  • Input:

    • container_id (string): ID from sandbox_initialize

  • Output: Confirmation message

Usage Tips

  • Session-based tools (sandbox_initialize ➔ run_js ➔ sandbox_stop) are ideal when you want to:

    • Keep a long-lived sandbox container open.

    • Run multiple commands or scripts in the same environment.

    • Incrementally install and reuse dependencies.

  • One-shot execution with run_js_ephemeral is perfect for:

    • Quick experiments or simple scripts.

    • Cases where you don’t need to maintain state or cache dependencies.

    • Clean, atomic runs without worrying about manual teardown.

  • Detached mode is useful when you want to:

    • Spin up servers or long-lived services on-the-fly

    • Expose and test endpoints from running containers

Choose the workflow that best fits your use-case!

Build

Compile and bundle:

npm install
npm run build

License

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Available Tools

7 tools
ai_generateC

Generate text using Google Gemini. Provide a prompt and optional model name.

ParametersJSON Schema
NameRequiredDescriptionDefault
maxTokensNoMaximum tokens in the response
modelNoGemini model namemodels/gemini-2.0-flash-exp
promptYesPrompt to send to Gemini

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states basic functionality without disclosing behavioral traits like rate limits, authentication needs, response formats, or potential errors. It mentions optional model selection but doesn't explain implications or defaults, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences that directly state the tool's purpose and required inputs. Every word earns its place, and it's front-loaded with the core functionality, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of AI text generation, no annotations, and no output schema, the description is incomplete. It lacks details on response handling, error cases, model defaults (though schema covers this), and behavioral aspects like token limits or safety considerations, making it inadequate for full contextual understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters (prompt, model, maxTokens). The description adds minimal value by mentioning 'prompt and optional model name' but doesn't provide additional meaning beyond the schema, such as prompt best practices or model selection guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Generate text') and the resource/technology ('using Google Gemini'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools (none of which are text generation tools), so it doesn't reach the highest score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance with 'Provide a prompt and optional model name,' but lacks explicit when-to-use instructions, alternatives, or context about when this tool is preferred over others. No sibling tools are text generators, so differentiation isn't needed, but general usage context is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
dependenciesYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (fetches and returns .d.ts text) but lacks details on behavioral traits such as error handling (e.g., what happens if a package doesn't exist), performance (e.g., rate limits or timeouts), or side effects (e.g., whether it caches results or makes network calls). The description is functional but misses key operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the core functionality, and the second provides usage context. Every sentence earns its place with no redundant information, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (fetching TypeScript definitions for dependencies), no annotations, no output schema, and low schema description coverage, the description is incomplete. It covers the purpose and usage well but lacks details on parameters, behavioral traits, and output format (beyond mentioning '.d.ts text'). This leaves gaps for an AI agent to fully understand how to invoke and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It mentions 'array of npm package names (and optional versions)', which aligns with the 'dependencies' parameter in the schema. However, it doesn't explain the structure (e.g., that 'dependencies' is an array of objects with 'name' and optional 'version'), provide examples, or detail constraints (e.g., format of package names). This adds minimal semantic value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'fetch whether each package ships its own TypeScript definitions or has a corresponding @types/… package, and return the raw .d.ts text.' This specifies the verb (fetch/return), resource (TypeScript definitions), and output (raw .d.ts text). However, it doesn't explicitly distinguish this tool from its siblings (like ai_generate or run_js), which are unrelated but still siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'Useful when you're about to run a Node.js script against an unfamiliar dependency and want to inspect what APIs and types it exposes.' This gives a specific scenario (inspecting dependencies before running a script) but doesn't explicitly state when not to use it or mention alternatives among the sibling tools, which are unrelated to dependency analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript code to run inside the container.
container_idYesDocker container identifier
dependenciesNoA list of npm dependencies to install before running the code. Each item must have a `name` (package) and `version` (range). If none, returns an empty array.
listenOnPortNoIf set, leaves the process running and exposes this port to the host.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and discloses key behavioral traits: it requires manual cleanup ('manually stop the sandbox to free resources'), specifies execution environment constraints ('valid ESModules', 'Node.js processes'), and describes persistence mechanisms ('mounted volume', './files directory'). It doesn't mention error handling, timeouts, or resource limits, but covers essential operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized (4 sentences) and front-loaded with core functionality. Every sentence adds value: first states purpose, second covers cleanup requirement, third provides usage context and ESModules requirement, fourth explains file system constraints. Minor redundancy exists in mentioning 'Node.js processes' after 'JavaScript code'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 4 parameters, no annotations, and no output schema, the description provides substantial context about execution environment, persistence, cleanup, and sibling differentiation. It lacks details about return values/output format and error cases, but covers most operational aspects needed for effective use given the structured data available.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific context beyond the schema, mainly reinforcing that code must be ESModules and dependencies are npm packages. It doesn't provide additional syntax examples or constraints not already in schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Install npm dependencies and run JavaScript code') and resource ('inside a running sandbox container'). It distinguishes from siblings like 'run_js_ephemeral' by emphasizing environment reuse across multiple executions, and from 'sandbox_exec' by specifying JavaScript/ESModules context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('Best for complex workflows where you want to reuse the environment across multiple executions') and when not to (implied by mentioning ephemeral alternatives). It also states prerequisites ('After running, you must manually stop the sandbox to free resources') and file system constraints ('always need to read from and write to the "./files" directory').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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");
ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript code to run inside the ephemeral container.
dependenciesNoA list of npm dependencies to install before running the code. Each item must have a `name` (package) and `version` (range). If none, returns an empty array.
imageNoDocker image to use for ephemeral execution. e.g. - **node:lts-slim**: Node.js LTS version, slim variant. (Lightweight and fast for JavaScript execution tasks.) - **mcr.microsoft.com/playwright:v1.52.0-noble**: Playwright image for browser automation. (Preconfigured for running Playwright scripts.) - **alfonsograziano/node-chartjs-canvas:latest**: Chart.js image for chart generation and mermaid charts generation. ('Preconfigured for generating charts with chartjs-node-canvas and Mermaid. Minimal Mermaid example: import fs from "fs"; import { run } from "@mermaid-js/mermaid-cli"; fs.writeFileSync("./files/diagram.mmd", "graph LR; A-->B;", "utf8"); await run("./files/diagram.mmd", "./files/diagram.svg");)node:lts-slim

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the ephemeral/disposable nature, automatic cleanup, ESModules requirement, file persistence rules (read/write to './files' directory), and support for various file types. It doesn't mention execution time limits, error handling, or output format, which keeps it from a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first defines the tool, the second specifies ESModules requirement and use case, the third explains file persistence rules, and the example illustrates usage. It could be slightly more concise by integrating the file persistence note with the example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (ephemeral execution with dependencies) and no annotations or output schema, the description does well to cover purpose, usage, behavioral traits, and provide an example. It lacks details on execution limits, error responses, or output structure, but for a tool with rich schema coverage and clear context, it's largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it implies the 'code' parameter must be valid ESModules and mentions the './files' directory context, but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('run', 'clean up') and resources ('JavaScript snippet', 'temporary disposable container', 'npm dependencies'). It distinguishes from siblings like 'run_js' (which likely lacks the ephemeral/cleanup aspect) and 'sandbox_exec' (which may require manual sandbox management).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('ideal for simple one-shot executions without maintaining a sandbox or managing cleanup manually') and provides clear context for alternatives. It distinguishes from siblings by emphasizing the ephemeral nature and automatic cleanup, which contrasts with tools like 'sandbox_exec' that likely require manual sandbox management.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sandbox_execB

Execute one or more shell commands inside a running sandbox container. Requires a sandbox initialized beforehand.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandsYes
container_idYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the prerequisite. It lacks details on behavioral traits such as execution environment, error handling, output format, or security implications (e.g., destructive potential of shell commands). This is a significant gap for a tool that executes commands.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every word earns its place without redundancy. It's efficiently structured and appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of executing shell commands in a container, no annotations, and no output schema, the description is incomplete. It misses critical details like what the tool returns, how errors are handled, or execution limits. This inadequately supports an AI agent in using the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it doesn't explain parameters beyond what the schema implies. It mentions 'shell commands' and 'sandbox container', which loosely map to 'commands' and 'container_id', but adds no syntax, format, or constraints. Baseline 3 is appropriate as the schema defines parameters clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Execute shell commands') and the target ('inside a running sandbox container'), which is specific and actionable. It distinguishes from siblings like 'sandbox_initialize' by focusing on execution rather than setup, though it doesn't explicitly contrast with 'run_js' tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context by stating 'Requires a sandbox initialized beforehand', which implicitly guides when to use this tool versus 'sandbox_initialize'. However, it doesn't explicitly mention alternatives like 'run_js' for non-shell commands or exclusions for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sandbox_initializeB

Start a new isolated Docker container running Node.js. Used to set up a sandbox session for multiple commands and scripts.

ParametersJSON Schema
NameRequiredDescriptionDefault
imageNo
portNoIf set, maps this container port to the host

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating an 'isolated Docker container' and a 'sandbox session for multiple commands,' which hints at a persistent environment, but fails to detail critical aspects like resource limits, session lifecycle, cleanup behavior, or error handling. This leaves significant gaps for a tool that likely involves system-level operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place with zero redundancy, making it highly efficient and easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of initializing a Docker container with Node.js, no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on what the tool returns (e.g., container ID, session handle), error conditions, or operational constraints, making it inadequate for safe and effective use by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 50% (only the 'port' parameter has a description), and the description adds no additional parameter information beyond what the schema provides. It doesn't explain the 'image' parameter (e.g., default values or constraints) or clarify the relationship between parameters. Since schema coverage is moderate, the baseline score of 3 is appropriate, as the description doesn't compensate for the gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Start a new isolated Docker container') and resource ('running Node.js'), with the specific purpose of setting up a sandbox session for multiple commands. However, it doesn't explicitly differentiate from sibling tools like 'sandbox_exec' or 'sandbox_stop', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('Used to set up a sandbox session for multiple commands and scripts'), suggesting this tool initiates a session while others like 'sandbox_exec' might operate within it. However, it lacks explicit guidance on when to use this versus alternatives (e.g., 'run_js_ephemeral' for one-off scripts) or any exclusions, leaving room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sandbox_stopA

Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize.

ParametersJSON Schema
NameRequiredDescriptionDefault
container_idYes

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates destructive behavior ('Terminate and remove'), which is helpful. However, it lacks details on potential side effects (e.g., data loss, cleanup processes), error conditions, or confirmation requirements, leaving gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero waste—each sentence adds critical information (action and usage context). It is appropriately sized and front-loaded with the core purpose, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operation with one parameter), no annotations, and no output schema, the description is reasonably complete. It covers purpose and usage well but could improve by addressing behavioral aspects like data persistence or error handling, which are relevant for a cleanup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It doesn't explicitly mention the 'container_id' parameter, but the context ('a running sandbox container') implicitly clarifies what this parameter refers to. Since there's only one parameter, the baseline is high, but the lack of explicit parameter discussion slightly reduces the score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Terminate and remove') and resource ('a running sandbox container'), distinguishing it from sibling tools like sandbox_initialize and sandbox_exec. It precisely defines what the tool does without being vague or tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('after finishing work in a sandbox initialized with sandbox_initialize') and implies when not to use it (e.g., while still working in the sandbox). It provides clear context and references a specific alternative/sibling tool for setup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • First observedai_generate
    • First observedget_dependency_types
    • First observedrun_js
    • First observedrun_js_ephemeral
    • First observedsandbox_exec
    • First observedsandbox_initialize
    • First observedsandbox_stop
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Docker MCP Server

    zaycruz
    A
    license
    Not graded
    quality
    F
    maintenance
    Facilitates isolated code execution within Docker containers, enabling secure multi-language script execution and integration with language models like Claude via the Model Context Protocol.
    5
    MIT

  • MCP QuickJS Runner

    jlucaso1
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides secure execution of arbitrary JavaScript code within a sandboxed QuickJS WASM environment, allowing language models or other MCP clients to safely run JavaScript code snippets without compromising the host system.
    4
    -

  • Node.js Sandbox MCP Server

    alfonsograziano
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables running arbitrary JavaScript code in isolated Docker containers with on-the-fly npm dependency installation, supporting both ephemeral one-shot executions and persistent sandbox environments.
    134
    157
    -

  • Node Code Sandbox MCP

    mozicim
    F
    license
    A
    quality
    B
    maintenance
    A secure Node.js execution environment that allows coding agents and LLMs to run JavaScript dynamically, install NPM packages, and retrieve results while adhering to the Model Control Protocol.
    7
    134
    4
    -

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ssdeanx/node-code-sandbox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server