The Capsule Bash MCP server lets you run bash commands in secure, persistent, isolated WebAssembly sandboxes with no access to the host filesystem or network.
run: Execute a bash command in a sandboxed environment, returning stdout, stderr, exit code, a filesystem diff of what changed, and current shell state (cwd + env vars). Commands sharing the same session_id maintain persistent state across calls.
reset: Wipe a session's filesystem and shell state (cwd, env vars) back to initial values.
sessions: List all currently active shell sessions.
Each session runs in its own WebAssembly address space, ensuring full isolation between sessions with no cross-session data leakage.
Capsule Bash MCPAn MCP server that gives your AI agent the ability to run bash commands in a secure, persistent, sandboxed environment.
Each session runs inside a WebAssembly sandbox. The sandbox provides:
Persistent state: cwd, env vars, and filesystem changes persist across commands within a session
Filesystem diff: every run response includes a diff of what changed on disk
Isolated memory: each session gets its own address space, no cross-session leakage
No host access: the sandbox cannot reach your host filesystem or network
Learn more about Capsule Bash.
Related MCP server: anvil
Tool | Description |
| Run a bash command in a sandboxed session. Returns stdout, stderr, exit code, filesystem diff, and current state (cwd + env). |
| Reset the filesystem and state (cwd, env vars) for a session back to their initial values. |
| List all active sessions. |
Commands within the same session_id share cwd, environment variables, and filesystem state across calls.
Ask your AI agent:
"Write a Python script that averages a list of numbers."
The agent calls run sequentially:
{ "command": "mkdir -p /data && cd /data", "session_id": "custom_session" }
{ "command": "echo 'nums = [x for x in [1, 2, 3, []] if isinstance(x, int)]\nprint(sum(nums) / len(nums))' > avg.py", "session_id": "custom_session" }
{ "command": "python3 avg.py", "session_id": "custom_session" }Each call returns stdout, stderr, exitCode, a filesystem diff, and the updated state to enrich context and keep trace in conversation history.
Add to your MCP client configuration (e.g. Claude Desktop, Cursor):
{
"mcpServers": {
"bash": {
"command": "npx",
"args": ["-y", "@capsule-run/bash-mcp"]
}
}
}Not all bash commands and options are implemented. Feel free to open an issue if a command is missing or behaves unexpectedly.
Reset a session's filesystem and shell state (cwd, env vars) to their initial values. Useful to start fresh without creating a new session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | The session to reset. Defaults to 'default'. | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly explains that the tool resets filesystem and shell state to initial values, which is specific and transparent about the behavior. No side effects or additional information is provided, but the action is straightforward.
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 consists of two sentences, both front-loaded with essential information: the action and scope in the first sentence, usage context in the second. No wasted words.
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 simplicity (one parameter, no output schema), the description provides all necessary information: what it does, what it affects, and when to use it. No gaps remain.
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 input schema has 100% description coverage, and the description adds no additional meaning beyond what the schema already provides for the single parameter 'session_id'. Baseline of 3 is appropriate.
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 verb 'reset' and the resource 'session's filesystem and shell state', specifying what is reset (cwd, env vars) and distinguishing from siblings 'run' and 'sessions' which have different purposes.
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 explicitly says 'useful to start fresh without creating a new session', giving a clear usage scenario and implying an alternative (creating a new session). However, it does not explicitly state when not to use it or list other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a Bash command in the sandboxed environment
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The bash command to execute. | |
| session_id | No | Identifier for the shell session. Commands within the same session share cwd, env, and filesystem state. Defaults to 'default'. | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only notes the sandboxed environment but fails to describe side effects (e.g., file system changes, output handling, error behavior) or any permissions needed.
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 a single, focused sentence with no wasted words. It is appropriately sized for a simple tool and front-loades key information.
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 simplicity (2 parameters, no output schema, no annotations), the description is adequate but not thorough. It lacks information about return values (e.g., stdout/stderr) and potential side effects, which could help an agent understand the tool's full behavior.
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%, with clear explanations for both parameters (command and session_id). The tool description adds no extra parameter information. Baseline of 3 is appropriate as the schema already documents parameter semantics.
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 'Execute a Bash command in the sandboxed environment' clearly states the action (execute) and the resource (Bash command in sandbox). It distinguishes from siblings 'reset' and 'sessions' by implying this tool is for running commands, not managing sessions.
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?
No guidance is provided on when to use this tool versus alternatives like 'reset' or 'sessions'. The description does not mention prerequisites, scenarios, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active session IDs and their current state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description states the tool lists active sessions, conveying a non-destructive, read-only behavior. But it omits details like whether state includes sub-attributes or if sessions are global.
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?
A single, front-loaded sentence with no wasted words. Efficiently captures the core functionality.
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 no output schema, the description could be more complete by hinting at return structure or example use. It covers the basic purpose but lacks actionable output details.
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?
No parameters; schema coverage is 100% by default. The description does not need to add param info. Baseline 4 for 0 parameters.
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?
Describes a specific action (list) and resource (active session IDs and state). Clearly distinguishes from siblings 'reset' and 'run' which imply modification actions.
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 implies a read-only listing use case, and with siblings being action-oriented, the context is clear. However, no explicit when-not or alternative guidance is provided.
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.
v0.1.0resetrunsessionsEach tool has a unique, clear purpose: reset reverts state, run executes commands, and sessions lists active sessions. No ambiguity or overlap exists.
All tool names are single, imperative verbs (reset, run, sessions) following a consistent, simple pattern.
Three tools is well-scoped for a bash sandbox server, covering essential operations without superfluous or missing tools.
The set covers core actions (run, reset, list sessions) but lacks explicit session creation; likely sessions are created implicitly, leaving a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/capsulerun/bash'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
