在一次性 Docker 容器里执行一段 JavaScript

适合谁

如果你已经能在本机跑 Docker，并希望通过 MCP 把一段任意 JavaScript 丢进临时容器执行，必要时再现场安装 npm 依赖，这个服务器对得上。官方说明它是实现 Model Context Protocol 的 Node.js 服务，专门在短暂的 Docker 容器里运行任意 JavaScript，并支持即时安装 npm 依赖。

它不适合 Docker 未安装或未处于运行状态的机器。当前摘录只描述了「一次性脚本」和「Detached Mode 让容器在脚本结束后保持存活」两类能力，没有给出工具函数名、参数表或资源限额；如果你需要一份可照抄的调用签名，证据到这里就停了。

第一次使用应选择一次性、用完即弃的容器，而不是让容器继续活着。执行任意脚本是写入向动作：会新建容器、跑你给出的代码，并可能拉取依赖。

3 分钟完成第一次尝试

先确认 Docker 已经安装并且正在运行。官方推荐的主路径是在 MCP 客户端的服务器配置里放入下面这一段，不要并列再写一套别的安装器：

      "command": "npx",
      "args": ["-y", "node-code-sandbox-mcp"],

把这段放进你正在使用的 MCP 客户端配置位置。摘录没有写死配置文件名，所以不要把某个客户端路径写成已证实。保存并让该服务器重新加载。

动手前先核两点：Docker 守护进程确实在跑；你准备提交的脚本是自己要执行的内容。副作用是：服务会新建一个一次性 Docker 容器，在里面执行这段 JavaScript，并可能当场安装 npm 依赖。确认这两点后，再发出「在一个全新的一次性容器里跑一段一次性 JS 脚本」的请求。第一次不要打开 Detached Mode。

成功信号是这次请求按一次性容器路径跑起来，而不是提示 Docker 未运行，或 npx 无法拉起 node-code-sandbox-mcp。这不是零风险读取：容器、脚本执行和依赖安装都会发生，也不等于无网络或无隐私边界。

使用案例

案例一：跑一段用完即弃的脚本。摘录写明可以在一个全新的一次性容器里运行一段一次性 JS 脚本。你应先确认脚本内容，再提交。能核到的结果是这段脚本在新容器里被执行；返回字段、标准输出格式和工具名都没有出现在当前摘录里，不要把具体字段写成已证实。

案例二：需要脚本结束后容器仍保持存活，例如长时间运行的服务。摘录写明 Detached Mode 可以在脚本执行后保持容器存活。这比一次性路径副作用更大：容器会留下来。摘录没有给出停止、删除或撤销步骤，因此不要把「关掉容器」写成官方恢复路径。只有在你明确需要容器继续活着时才走这条。

这两个案例分别对应「一次性执行」和「执行后保活」，不要混成同一次未证实的调用。

使用边界

使用前提是 Docker 必须已安装并正在运行。主安装路径是 npx -y node-code-sandbox-mcp。能力上能核到：在全新一次性容器里跑一段 JS；以及 Detached Mode 在脚本结束后保持容器存活。即时安装 npm 依赖也被写进了总体说明，但安装范围、缓存位置和网络策略没有出现在当前摘录。

官方页面是 https://github.com/alfonsograziano/node-code-sandbox-mcp 。摘录没有给出凭据字段、客户端名单、CPU 或内存数字，也没有撤销或清理命令。不要把容器执行理解成可随意回滚，也不要补未出现的工具名和参数。