Node Code Sandbox MCP에 오신 것을 환영합니다! 이 저장소는 AI 애플리케이션에 최적화된 안전한 Node.js 실행 환경을 제공합니다. 코딩 에이전트와 대규모 언어 모델(LLM)이 JavaScript를 동적으로 실행하고, NPM 패키지를 설치하고, 결과를 검색할 수 있도록 지원합니다. 이 기능은 모델 제어 프로토콜(MCP)을 준수하는 동시에 코드 생성, 테스트 및 대화형 지원을 용이하게 합니다.
Related MCP server: MCP QuickJS Runner
동적 JavaScript 실행 : 안전한 환경에서 JavaScript 코드를 실행합니다.
NPM 패키지 지원 : 필요에 따라 NPM 패키지를 설치하고 사용하세요.
대화형 지원 : AI 에이전트를 위한 코드 생성 및 테스트 기능.
MCP 호환성 : 모델 제어 프로토콜과 원활하게 작동합니다.
샌드박싱 : 승인되지 않은 접근을 방지하기 위해 안전한 실행을 보장합니다.
Node Code Sandbox MCP를 시작하려면 릴리스 섹션에서 최신 버전을 확인하세요. 적절한 파일을 다운로드하고 실행하여 환경을 설정하세요.
Node.js(버전 14 이상)
NPM(노드 패키지 관리자)
JavaScript 및 AI 개념에 대한 기본 지식
저장소를 복제합니다.
지엑스피1
프로젝트 디렉토리로 이동합니다.
cd node-code-sandbox-mcp종속성 설치:
npm install서버를 시작합니다:
npm start이제 Node Code Sandbox MCP가 실행 중입니다!
서버가 실행되면 JavaScript 코드를 실행할 수 있습니다. 간단한 예시는 다음과 같습니다.
브라우저를 열고 http://localhost:3000 으로 이동합니다.
JavaScript 코드를 입력할 수 있는 인터페이스가 표시됩니다.
코드를 입력하고 "실행"을 클릭하세요.
결과는 입력 영역 아래에 표시됩니다.
console.log("Hello, world!");NPM 패키지를 설치하려면 인터페이스에서 다음 명령을 사용하세요.
npm install <package-name>예를 들어:
npm install lodash노드 코드 샌드박스 MCP는 샌드박스 환경과 상호 작용하기 위한 여러 가지 API 엔드포인트를 제공합니다.
엔드포인트 : /execute
방법 : POST
요청 본문 :
{
"code": "your JavaScript code here"
}응답 :
{
"result": "output of your code"
}엔드포인트 : /install
방법 : POST
요청 본문 :
{
"package": "package-name"
}응답 :
{
"status": "success",
"message": "Package installed successfully"
}Node Code Sandbox MCP에 대한 여러분의 기여를 환영합니다! 개선 사항이나 새로운 기능에 대한 아이디어가 있으시면 다음 단계를 따르세요.
저장소를 포크합니다.
새로운 브랜치를 만듭니다: git checkout -b feature/YourFeature .
변경 사항을 적용하고 커밋합니다: git commit -m 'Add some feature' .
브랜치에 푸시합니다: git push origin feature/YourFeature .
풀 리퀘스트를 엽니다.
귀하의 코드가 당사의 코딩 표준을 준수하는지 확인하고, 해당되는 경우 테스트를 포함하세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 라이선스 파일을 참조하세요.
질문이나 피드백이 있으시면 GitHub 이슈를 통해 문의하시거나 저장소 소유자에게 연락해 주세요.
Node Code Sandbox MCP를 이용해 주셔서 감사합니다! 최신 릴리스 정보는 릴리스 섹션을 참조하세요. 즐거운 코딩 되세요!
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
