¡Bienvenido a Node Code Sandbox MCP! Este repositorio proporciona un entorno de ejecución Node.js seguro, diseñado para aplicaciones de IA. Permite a los agentes de codificación y a los grandes modelos de lenguaje (LLM) ejecutar JavaScript dinámicamente, instalar paquetes NPM y obtener resultados. Esta funcionalidad facilita la generación de código, las pruebas y la asistencia interactiva, todo ello cumpliendo con el Protocolo de Control de Modelos (MCP).
Related MCP server: MCP QuickJS Runner
Ejecución dinámica de JavaScript : ejecute código JavaScript en un entorno seguro.
Compatibilidad con paquetes NPM : instale y utilice paquetes NPM según sea necesario.
Asistencia interactiva : capacidades de generación y prueba de código para agentes de IA.
Compatibilidad con MCP : funciona perfectamente con el Protocolo de control de modelos.
Sandbox : garantiza la ejecución segura para evitar el acceso no autorizado.
Para empezar a usar Node Code Sandbox MCP, consulta la sección de Versiones para ver la última versión. Descarga y ejecuta los archivos necesarios para configurar tu entorno.
Node.js (versión 14 o superior)
NPM (Administrador de paquetes de nodos)
Conocimientos básicos de JavaScript y conceptos de IA
Clonar el repositorio:
git clone https://github.com/mozicim/node-code-sandbox-mcp.gitNavegue hasta el directorio del proyecto:
cd node-code-sandbox-mcpInstalar dependencias:
npm installIniciar el servidor:
npm start¡Ahora tu Node Code Sandbox MCP está en funcionamiento!
Una vez que el servidor esté en funcionamiento, puedes empezar a ejecutar código JavaScript. Aquí tienes un ejemplo sencillo:
Abra su navegador y navegue a http://localhost:3000 .
Verá una interfaz donde podrá ingresar código JavaScript.
Ingrese su código y haga clic en "Ejecutar".
Los resultados se mostrarán debajo del área de entrada.
console.log("Hello, world!");Para instalar un paquete NPM, utilice el siguiente comando en la interfaz:
npm install <package-name>Por ejemplo:
npm install lodashEl MCP de Node Code Sandbox proporciona varios puntos finales de API para interactuar con el entorno sandbox.
Punto final : /execute
Método : POST
Cuerpo de la solicitud :
{
"code": "your JavaScript code here"
}Respuesta :
{
"result": "output of your code"
}Punto final : /install
Método : POST
Cuerpo de la solicitud :
{
"package": "package-name"
}Respuesta :
{
"status": "success",
"message": "Package installed successfully"
}Agradecemos las contribuciones al MCP de Node Code Sandbox. Si tiene ideas para mejoras o nuevas funciones, siga estos pasos:
Bifurcar el repositorio.
Crea una nueva rama: git checkout -b feature/YourFeature .
Realice sus cambios y confirme: git commit -m 'Add some feature' .
Empujar a la rama: git push origin feature/YourFeature .
Abrir una solicitud de extracción.
Asegúrese de que su código cumpla con nuestros estándares de codificación e incluya pruebas cuando corresponda.
Este proyecto está licenciado bajo la Licencia MIT. Consulte el archivo de LICENCIA para más detalles.
Si tiene preguntas o comentarios, comuníquese a través de los problemas de GitHub o comuníquese con el propietario del repositorio.
Gracias por explorar Node Code Sandbox MCP. Para ver las últimas versiones, visita la sección "Lances" . ¡Disfruta programando!
Generate text using Google Gemini. Provide a prompt and optional model name.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt to send to Gemini | |
| model | No | Gemini model name | models/gemini-2.0-flash-exp |
| maxTokens | No | Maximum tokens in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('Generate text') but lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (e.g., text format, potential truncation). This leaves significant gaps for an AI agent to understand how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the tool's function and required inputs, with no wasted words. It's front-loaded and efficiently communicates the essentials without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an AI text generation tool with no annotations and no output schema, the description is incomplete. It fails to address key aspects like output format, error conditions, or usage constraints (e.g., token limits, model availability), which are crucial for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema already documents all parameters (prompt, model, maxTokens) with descriptions. The description adds minimal value by mentioning 'prompt and optional model name' but doesn't provide additional context beyond what's in the schema, such as typical use cases for maxTokens or model selection advice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('using Google Gemini'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like run_js or sandbox_exec), which might also involve text generation or execution in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 offers no explicit advice on when to use this tool versus alternatives (e.g., run_js for JavaScript execution or other AI tools if available). There's no mention of prerequisites, limitations, or specific contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| dependencies | Yes |
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 describes what the tool does (fetches TypeScript definitions) and the output (raw .d.ts text), which is helpful. However, it doesn't disclose important behavioral traits like whether this makes network calls, potential rate limits, authentication requirements, error handling, or what happens when packages don't have TypeScript definitions. The description adds value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. The first sentence clearly states the tool's function, and the second sentence provides useful context without unnecessary elaboration. Every sentence earns its place, and there's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (fetching TypeScript definitions for npm packages), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It explains the purpose and usage context well, but lacks details about behavioral traits, parameter specifics, and output format beyond 'raw .d.ts text.' For a tool that likely involves network calls and complex data retrieval, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'array of npm package names (and optional versions)' which maps to the 'dependencies' parameter, providing basic semantics. However, it doesn't explain the structure of the array items (objects with name and version properties), format expectations for version strings, or constraints on the array size. The description adds some meaning but doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 format. However, it doesn't explicitly distinguish this tool from its siblings (like run_js or sandbox_exec), which could potentially be used for similar dependency inspection tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 and motivation. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes | Docker container identifier | |
| dependencies | No | A 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. | |
| code | Yes | JavaScript code to run inside the container. | |
| listenOnPort | No | If set, leaves the process running and exposes this port to the host. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context beyond the input schema. It discloses that resources must be manually freed after running, specifies ESModules requirement, explains persistence via the './files' directory, and hints at environment reuse. It doesn't mention error handling or output format, but covers key operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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: installation/running, manual cleanup, ESModules requirement, use case, and file I/O guidance. It could be slightly more structured but avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sandbox execution with dependencies) and lack of annotations/output schema, the description does well to cover key aspects: purpose, usage context, behavioral constraints, and file persistence. It doesn't detail error responses or output structure, but provides enough for basic agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific semantics: it implies 'dependencies' are npm packages and 'code' is JavaScript, but doesn't elaborate beyond what the schema already documents. No contradictions or significant enhancements are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 sibling tools like 'run_js_ephemeral' by emphasizing reusability across multiple executions and the need to manually stop the sandbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Best for complex workflows where you want to reuse the environment across multiple executions.' It implicitly contrasts with ephemeral alternatives by noting the need to manually stop the sandbox, and it specifies prerequisites like valid ESModules syntax and file I/O requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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");| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker 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 |
| dependencies | No | A 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. | |
| code | Yes | JavaScript code to run inside the ephemeral container. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the container is temporary and disposable, cleanup is automatic, code must be ESModules, and files must be read/written from './files' directory for persistence. However, it lacks details on execution limits, error handling, or output format, which are important for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. It includes an example that clarifies usage, but the example is lengthy and could be more concise. Overall, most sentences earn their place by adding useful context, though some details could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing JavaScript in containers with dependencies) and lack of annotations and output schema, the description is moderately complete. It covers the ephemeral nature, ESModules requirement, and file persistence, but misses details on execution behavior, error responses, or limitations, which are crucial for an agent to use it correctly without structured output guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (image, dependencies, code). The description adds minimal value beyond the schema: it mentions 'optional npm dependencies' and provides an example with code, but does not elaborate on parameter usage or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a JavaScript snippet in a temporary disposable container with optional npm dependencies, then automatically clean up.' It specifies the verb ('Run'), resource ('JavaScript snippet'), and distinguishes it from siblings by emphasizing ephemeral execution and automatic cleanup, unlike persistent sandbox tools like run_js or sandbox_exec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: 'Ideal for simple one-shot executions without maintaining a sandbox or managing cleanup manually.' It implies usage for temporary tasks but does not explicitly state when not to use it or name alternatives among siblings like run_js or sandbox_exec, which might be better for persistent executions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one or more shell commands inside a running sandbox container. Requires a sandbox initialized beforehand.
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes | ||
| commands | Yes |
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 the prerequisite of an initialized sandbox, which is useful context. However, it lacks details on critical behaviors such as whether commands run sequentially or in parallel, what happens on command failure, output format, security implications, or resource limits. For a tool that executes shell commands in a container, this is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that are front-loaded and waste no words. The first sentence states the core action and resource, and the second adds a crucial prerequisite, making every sentence earn its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, and 0% schema description coverage, the description is incomplete. It misses details on behavioral traits, parameter usage, and output handling, which are essential for safe and effective tool invocation. The prerequisite note helps, but overall, it's inadequate for a tool with this level of potential impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It implies the need for a 'container_id' and 'commands' by referencing a sandbox container and shell commands, but doesn't explain what a container_id is, how to obtain it, or the format/syntax for commands. Since there are only 2 parameters, the baseline is higher, but the description adds minimal semantic value beyond what's inferred from the tool name and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('inside a running sandbox container'), making the purpose specific and understandable. It distinguishes from sibling tools like 'sandbox_initialize' and 'sandbox_stop' by focusing on command execution rather than container lifecycle management. However, it doesn't explicitly differentiate from 'run_js' or 'run_js_ephemeral' which might also execute code in some environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Requires a sandbox initialized beforehand,' which implies a prerequisite and suggests when to use this tool (after initialization). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'run_js' for JavaScript execution versus shell commands, leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new isolated Docker container running Node.js. Used to set up a sandbox session for multiple commands and scripts.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | ||
| port | No | If set, maps this container port to the host |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool starts an 'isolated Docker container' and is for 'multiple commands and scripts,' implying persistence and isolation. However, it doesn't disclose critical behavioral traits such as whether this requires Docker permissions, what happens to existing containers, how long the container persists, resource limits, or error handling. For a tool that initializes a Docker container with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 sentence adds value: the first defines the action, and the second explains the broader use case. There's no redundancy or unnecessary information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is inadequate. It lacks details on behavioral aspects (e.g., permissions, persistence, error handling), doesn't clarify parameter usage, and provides minimal guidance on integration with sibling tools. For a tool with this level of complexity, it should do more to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'port' has a description). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain the 'image' parameter (e.g., default Node.js version, allowed images) or provide additional context for 'port.' With partial schema coverage, the description doesn't compensate for the undocumented 'image' parameter, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start a new isolated Docker container running Node.js.' It specifies the verb ('Start'), resource ('isolated Docker container'), and technology ('Node.js'). However, it doesn't explicitly differentiate from sibling tools like 'sandbox_exec' or 'run_js_ephemeral' beyond mentioning it's 'Used to set up a sandbox session for multiple commands and scripts.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by stating it's 'Used to set up a sandbox session for multiple commands and scripts,' suggesting this is for initializing a reusable environment. However, it doesn't explicitly state when to use this versus alternatives like 'run_js_ephemeral' (for one-off scripts) or 'sandbox_exec' (for commands within an existing sandbox). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize.
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'Terminate[s] and remove[s]' a container, which implies destructive behavior and cleanup. However, it doesn't mention potential side effects (e.g., data loss), permissions required, or error conditions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides usage guidelines. It's front-loaded with the core action 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with no annotations and no output schema, the description is mostly complete: it covers purpose, usage, and behavioral intent. However, it lacks details on return values or error handling, which would be helpful for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter, the description adds no explicit parameter information. However, the context implies 'container_id' refers to a sandbox from sandbox_initialize. Since there's only one required parameter, the baseline is 4, as minimal parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 target resource ('a running sandbox container'), distinguishing it from sibling tools like sandbox_initialize (which creates) and sandbox_exec (which runs commands). It uses precise verbs that convey both stopping and cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Should be called after finishing work in a sandbox initialized with sandbox_initialize.' This clearly defines when to use this tool versus alternatives (e.g., not for ongoing execution) and references the prerequisite sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
ai_generateget_dependency_typesrun_jsrun_js_ephemeralsandbox_execsandbox_initializesandbox_stopMost 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Execute code in 8 languages (Python, JS, TS, Go, Java, C++, C, Bash) in gVisor sandboxes.
Artifact store for AI agents. Hosted OAuth at mcp.artifacta.io/mcp; local stdio via npm/PyPI.
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mozicim/node-code-sandbox-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
