The first decision is the shape: one-shot costs a container start on every call, while the initialise, run, stop cycle keeps installed dependencies and files between runs and leaves a container alive until it is stopped on purpose. get_dependency_types is the unusual member of the set — pulling .d.ts text before generating code against an unfamiliar package removes a whole class of confident wrong guesses. Everything rests on a working Docker daemon; there is no alternative execution path in the tool set if containers are unavailable.
A code-execution server that starts Node.js containers on the local Docker daemon, either as a disposable one-shot or as a session you initialise, reuse and stop.
- Two execution shapes: run_js_ephemeral for a snippet in a container that cleans itself up, and sandbox_initialize with run_js and sandbox_stop when the environment should survive several runs
- Npm dependencies installed per run, so a snippet can pull the library it needs instead of being confined to the standard library
- Shell access inside a running container through sandbox_exec, for the steps a JavaScript entry point does not cover
- Type inspection before the code is written — get_dependency_types reports whether a package ships its own definitions or has an @types package, and returns the .d.ts text
- Npm discovery in the same session, returning package name, description and a README snippet
- A port on initialise and listenOnPort on run_js, for code that serves instead of exiting
A local Docker daemon the server can start containers on, and an image for it to run. Code must be valid ES modules using import and export, and anything read or written from the sandbox goes through the ./files directory. A session opened with sandbox_initialize keeps its container running until sandbox_stop is called.
One command — npx -y node-code-sandbox-mcp