Skip to main content
Glama
Kiln-AI

Kilntainers

Official
by Kiln-AI

Kilntainers is an MCP server that gives LLM agents isolated Linux sandboxes for executing shell commands.

  • 🧰 Multiple backends: Containers (Docker, Podman), cloud-hosted micro-VMs (Modal, E2B), and WebAssembly sandboxes (WASM BusyBox, or any WASM module).

  • 🏝️ Isolated per agent: Every agent gets its own dedicated sandbox β€” no shared state, no cross-contamination.

  • 🧹 Ephemeral: Sandboxes live for the duration of the MCP session, then are shut down and cleaned up automatically.

  • πŸ”’ Secure by design: The agent communicates with the sandbox over MCP β€” it doesn’t run inside it. No agent API keys, code, or prompts are exposed to the sandbox.

  • πŸ”Œ Simple MCP interface: A single MCP tool, sandbox_exec, lets your agent run any Linux command.

  • πŸ“ˆ Scalable: Scale from a few agents on your laptop to thousands running in parallel in the cloud.

Why Kilntainers?

Agents are already excellent at using terminals, and can save thousands of tokens by leveraging common Linux utilities like grep, find, jq, awk, etc. However giving an agent access to the host OS is a security nightmare, and running thousands of parallel agents on a service is painful. Kilntainers gives every agent its own isolated, ephemeral sandbox.

Related MCP server: shemcp

Quick Start

Install and run from CLI:

# install
uv tool install kilntainers
# starts with defaults: stdio MCP server, Docker, and Debian-slim (see options below)
kilntainers

Add to your MCP client (Claude, Cursor, etc.):

{
  "mcpServers": {
    "kilntainers": {
      "command": "kilntainers"
    }
  }
}

How It Works

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   MCP   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  LLM Agent  │◄───────►│  Kilntainers │◄────►│  Sandboxes              β”‚
β”‚  (client)   β”‚         β”‚  MCP Server  β”‚      β”‚  - Docker/Podman        β”‚
β”‚             β”‚         β”‚              β”‚      β”‚  - Cloud VM (Modal,E2B) β”‚
β”‚             β”‚         β”‚              β”‚      β”‚  - WASM Sandbox         β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
  1. An MCP client connects to Kilntainers

  2. On the first sandbox_exec call, Kilntainers creates an isolated sandbox. Each connection gets its own independent sandbox.

  3. Commands run inside the sandbox; stdout, stderr, and exit code are returned

  4. When the session ends, the sandbox is destroyed and resources are cleaned up.

Security: The agent communicates with the sandbox over MCP β€” it doesn't run inside it. This is intentional: agents often need secrets (API keys, system prompts, code), and those should never be exposed inside a sandbox where a prompt injection could exfiltrate them.

Agent Isolation & Sandbox Lifecycle: Each MCP connection starts its own isolated sandbox. In streaming HTTP mode, a single MCP server can host many sandboxes in parallel, and exec calls are routed to the sandbox associated with that connection. In stdio mode, the server runs a single sandbox per process. When a connection closes, its sandbox is shut down and deleted.

Backend Examples

See the CLI Reference for all arguments.

Docker and Podman (default)

Local containers via Docker or Podman. Any OCI image works.

kilntainers                                     # Docker + debian-slim (defaults)
kilntainers --image alpine --engine podman      # Podman + Alpine
kilntainers --image node:22 --network           # Node.js with networking

Cloud Containers & VMs

Modal.com

Hosted containers with sub-second startup via Modal.com. Scales to thousands of parallel sandboxes. Supports GPUs.

kilntainers --backend modal
kilntainers --backend modal --gpu A10G --region us-east  # GPU-accelerated

Authenticate via modal setup CLI or --modal-token-id / --modal-token-secret flags.

E2B

Cloud hosted micro-VM sandboxes from E2B.

kilntainers --backend e2b # Default Debian image
kilntainers --backend e2b --e2b-api-key ABCD --e2b-template my-custom-alpine # Custom image 

Authenticate with --e2b-api-key CLI arg, or E2B_API_KEY environment variable.

WASM Go BusyBox (Experimental)

Runs go-busybox in a WebAssembly sandbox. Not a full Linux environment, but provides common utilities (grep, awk, sed, ls, wc, sort, etc.) in a very lightweight and secure sandbox.

uv tool install kilntainers[wasm]  # WASM support is an optional dependency (+15MB)
kilntainers --backend go_busybox

WASM Runner

Run a custom WASM module as the sandbox backend. Provides agents a set tools compiled to WebAssembly, and an isolated filesystem.

uv tool install kilntainers[wasm]  # WASM support is an optional dependency (+15MB)
kilntainers --backend wasm --wasm-path ./my_tool.wasm

Installation

uv tool install kilntainers        # recommended
uv tool install kilntainers[wasm]  # optional, include WASM backends (+15MB)
pip install kilntainers            # also works with pip

Requires Python 3.13+. Docker backend requires Docker or Podman. The Modal and E2B backends require accounts to those services.

CLI Reference

usage: kilntainers [-h] [--backend {docker,go_busybox,modal,wasm}] [--transport {stdio,http}] [...]

MCP server providing isolated Linux sandboxes for LLM agent shell execution.

options:
  -h, --help            show this help message and exit

core options:
  --backend {docker,e2b,go_busybox,modal,wasm}
                        Backend to use (default: docker). Available: docker, e2b, go_busybox, modal, wasm
  --transport {stdio,http}
                        MCP transport (default: stdio)
  --host HOST           HTTP bind address (default: 127.0.0.1, HTTP mode only)
  --port PORT           HTTP listen port (default: 8435, HTTP mode only)
  --timeout TIMEOUT     Default exec timeout in seconds (default: 120)
  --output-limit OUTPUT_LIMIT
                        Max combined stdout+stderr bytes per exec (default: 2097152 = 2 MiB)
  --session-timeout SESSION_TIMEOUT
                        Idle session timeout in seconds (default: 300, HTTP mode only)
  --shell SHELL         Shell binary for command mode (e.g., /bin/bash, ash). Default: /bin/bash.
  --network             Enable network access in sandboxes (default: disabled)

tool description:
  --tool-instruction-override TOOL_INSTRUCTION_OVERRIDE
                        Replace the entire sandbox_exec tool description
  --extended-tool-instruction EXTENDED_TOOL_INSTRUCTION
                        Append to the backend's default tool description

docker backend options:
  --engine ENGINE       Container CLI binary (default: docker). Supports podman.
  --docker-host DOCKER_HOST
                        Docker daemon socket/address, passed as -H to the Docker CLI (e.g., "ssh://user@remote-host", "tcp://host:2375")
  --image IMAGE         Docker image (default: debian:bookworm-slim)
  --cpu CPU             Docker CPU limit (e.g., "1.5")
  --memory MEMORY       Docker memory limit (e.g., "512m")
  --docker-run-flag DOCKER_RUN_FLAGS
                        Additional flag passed to docker run. Repeatable. (e.g., --docker-run-flag "--pids-limit=256")

e2b backend options:
  --e2b-api-key E2B_API_KEY
                        E2B API key (overrides E2B_API_KEY environment variable)
  --e2b-template E2B_TEMPLATE
                        E2B template name or ID (default: base)
  --e2b-sandbox-timeout E2B_SANDBOX_TIMEOUT
                        Sandbox lifetime timeout in seconds (default: 3600)
  --e2b-metadata E2B_METADATA
                        Metadata key=value pairs (can be used multiple times)
  --e2b-env E2B_ENV     Environment variable key=value pairs (can be used multiple times)

modal backend options:
  --modal-token-id MODAL_TOKEN_ID
                        Modal token ID (overrides environment/default auth)
  --modal-token-secret MODAL_TOKEN_SECRET
                        Modal token secret (overrides environment/default auth)
  --modal-app-name MODAL_APP_NAME
                        Modal app name (default: kilntainers)
  --modal-cpu MODAL_CPU
                        CPU cores (fractional, default: 1.0)
  --modal-memory MODAL_MEMORY
                        Memory in MiB (default: 512)
  --gpu GPU             GPU type (e.g., "A10G", "H100")
  --region REGION       Geographic region (e.g., "us-east")
  --sandbox-timeout SANDBOX_TIMEOUT
                        Sandbox lifetime timeout in seconds (default: 3600, max 86400)

wasm backend options:
  --wasm-path WASM_PATH
                        Path to the .wasm file to execute (required for wasm backend)
  --wasm-max-memory WASM_MAX_MEMORY
                        Max WASM memory in MiB (default: 256)
  --wasm-fuel WASM_FUEL
                        WASM instruction fuel limit (default: unlimited)

Available Tools

1 tool
sandbox_execA

Execute a shell command in an isolated Debian Linux sandbox. Commands run in bash. Each call is independent β€” no state (shell variables, working directory) persists between calls (however filesystem does persist). Use the working_directory parameter or chain commands with && to control execution context.

To write files or pass data without shell escaping, use the stdin parameter (e.g., command="cat > file.txt" with content in stdin). Commands time out after 120 seconds by default (override with the timeout parameter for long-running operations).

ParametersJSON Schema
NameRequiredDescriptionDefault
commandNoShell command string (mutually exclusive with args).
argsNoList of arguments for direct execution (mutually exclusive with command).
stdinNoContent to pipe to stdin.
working_directoryNoWorking directory for the command (must be absolute).
timeoutNoTimeout in seconds (defaults to server config).

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: the sandbox is isolated, commands run in bash, no state persists between calls (except filesystem), default timeout of 120 seconds, and persistence of filesystem. This covers safety, execution environment, and operational constraints comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by essential behavioral details and usage tips in a logical flow. Every sentence adds valueβ€”explaining state persistence, parameter usage, and timeoutβ€”with zero waste or redundancy. It's efficiently structured 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (sandboxed execution with multiple parameters), no annotations, and no output schema, the description does an excellent job covering execution environment, behavioral traits, and parameter guidance. However, it lacks details on output format or error handling, which would be beneficial for an agent. It's nearly complete but has a minor gap in output expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 well. The description adds some value by explaining the purpose of stdin and working_directory in practical terms (e.g., 'to write files or pass data without shell escaping'), but it doesn't significantly enhance the parameter understanding beyond the schema. 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Execute a shell command'), the environment ('in an isolated Debian Linux sandbox'), and the execution context ('Commands run in bash'). It distinguishes this as a sandboxed execution tool with no sibling tools to differentiate from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use certain parameters (e.g., 'Use the working_directory parameter or chain commands with && to control execution context', 'To write files or pass data without shell escaping, use the stdin parameter'), but since there are no sibling tools, it cannot offer guidance on alternatives. It effectively explains usage scenarios without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.3
    • First observedsandbox_exec

TDQS

A4.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'sandbox_exec' has a clearly defined and distinct purpose of executing shell commands in an isolated sandbox environment.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'sandbox_exec' follows a clear verb_noun pattern (exec for execute, sandbox as the context), which would be consistent if more tools were added.

Tool Count2/5

A single tool is generally too few for most server purposes, as it limits functionality and can feel thin. For a sandbox execution server, additional tools for managing files, checking status, or listing processes might be expected to provide a more complete experience.

Completeness2/5

The tool surface is severely incomplete for a sandbox execution domain. While 'sandbox_exec' handles command execution, there are obvious gaps such as tools for file management (e.g., upload, download, list files), environment inspection, or process monitoring, which are common needs in such contexts.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    An MCP server that provides sandboxed shell command execution with configurable security policies, enabling safe AI-assisted command runs within a project repository.
    3
    15
    2
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    A sandboxed MCP server that executes shell commands inside ephemeral, locked-down Docker containers with no network by default, dropped capabilities, and an audit log, enabling secure agent-driven command execution.
    6
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kiln-AI/kilntainers'

If you have feedback or need assistance with the MCP directory API, please join our Discord server