LLM Sandbox MCP
LLM Sandbox MCP: an agent runs code in seven languages in a Docker, Podman or Kubernetes container and gets plots.
- 1,144 ★ on the repository
- Last commit
Extended access
Why this level
- Runs model-written code in a container; isolation depends on the backend and the Docker socket rights.
- Installs packages and may reach the network from the container.
Install
- Works in
Manual install
pip install 'llm-sandbox[mcp-docker]'For Podman use `[mcp-podman]`, for Kubernetes `[mcp-k8s]`.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Runs model-written code in a container; isolation depends on the backend and the Docker socket rights.
- Installs packages and may reach the network from the container.
This is third-party code. Review the repository files before installing.
What it does
LLM Sandbox is a library for safely running code written by a language model. Its MCP server gives an assistant three tools. `execute_code` takes code, a language (Python, JavaScript, Java, C++, Go, R, Ruby), a list of packages to install and a timeout of 30 seconds by default. `get_supported_languages` lists languages and `get_language_details` describes one: version, package manager, examples. Figures and plots created by the code are captured and returned along with the output. Isolation comes from the chosen backend: Docker by default, Podman or Kubernetes. The `BACKEND` variable sets it, and the matching `llm-sandbox[mcp-docker]`, `[mcp-podman]` or `[mcp-k8s]` extra is installed with it. CPU and memory limits come from environment variables such as `SANDBOX_CPUS`.
Who it is for. Agent developers and analysts who need model-written code to run in a separate container: calculations, plots, checking hypotheses.
Good fit when
- An agent computes statistics over data and returns a plot along with a table.
- A snippet in Go or Ruby needs checking without installing the language on the machine.
- The code needs third-party packages to run and the server installs them inside the container.
- A platform gives agents code execution in Kubernetes with resource limits.
Not a fit when
- You need direct access to project files, while the container sees only its own contents.
- The machine has no Docker, Podman or Kubernetes.
- Code has to run directly on the host with no isolation.
Example request
Compute the mean and median for this set of numbers in Python in the sandbox and return a distribution plot.MCP
- Transport
- stdio
- Authentication
- not required
Environment variables
BACKEND- Container backend: docker, podman or kubernetes, defaults to docker.
DOCKER_HOST- Docker or Podman socket address.
COMMIT_CONTAINER- Persist container state between calls, defaults to false.
Limitations
Code sent by the client is treated as untrusted, so persisting state between requests is off: `COMMIT_CONTAINER=false`. When enabled the image is committed under a separate tag, and only Docker and Micromamba support it. `KEEP_TEMPLATE=true` keeps the base image between requests and saves pulls. The server talks to the container engine socket (`DOCKER_HOST`), which is broad access to the machine, so restrict its rights. Kubernetes needs `KUBECONFIG`, and a custom pod manifest cannot be set through MCP.
How to disable. Remove the llm-sandbox entry from the MCP configuration and the package with `pip uninstall llm-sandbox`. Images and containers the server created are deleted with Docker, Podman or Kubernetes tools.
FAQ
How do I connect LLM Sandbox to Claude Desktop?
Install `pip install 'llm-sandbox[mcp-docker]'` and add an `llm-sandbox` server to `claude_desktop_config.json` with the command `python3`, the arguments `-m llm_sandbox.mcp_server.server` and the variables `BACKEND` and `DOCKER_HOST`.
How do I pick a backend?
The `BACKEND` variable accepts `docker`, `podman` or `kubernetes` and must match the installed extra (`mcp-docker`, `mcp-podman`, `mcp-k8s`). For Podman set the socket in `DOCKER_HOST`, for Kubernetes the `KUBECONFIG` path.
Are installed packages kept between calls?
No, by default the container is not committed. To keep packages across calls enable `COMMIT_CONTAINER=true`: the image is saved under a separate tag of the form `llm-sandbox-mcp/<language>:<hash>`.
Which languages are available?
Python, JavaScript, Java, C++, Go, R and Ruby. `get_supported_languages` and `get_language_details` return the list and details.
How do I limit container resources?
Through environment variables, for example `SANDBOX_CPUS` and `SANDBOX_CPU_COUNT` for the CPU. The server turns them into runtime settings for each session.
Discussion
No questions or reviews yet.
Related
MCP serversAn MCP to LSP bridge: the agent gets types, references, diagnostics and refactoring from rust-analyzer, pyright and gopls.
A bridge from an LSP language server to the agent: definitions, references, diagnostics, hover and symbol rename
A local sandbox for AI agents: they run code and actions in an isolated container exposed over MCP
A debugger with no IDE: an agent sets breakpoints, steps through code and inspects variables in ten languages
An MCP server for BSL syntax checks on BSL Language Server in Docker: send code, get back JSON errors and warnings with no Java install needed
The agent-lsp MCP server orchestrates language servers into agent workflows: callers, safe edits, renames and diagnostics.
README in short
The MCP server ships in the `llm-sandbox` package and works with both major versions of the Python MCP SDK. The repository's main product is a library with a common API for container and local Linux and Windows sandboxes.