Capsule server
# `Capsule` MCP Server
[](https://github.com/capsulerun/capsule/actions/workflows/mcp-integration-release.yml)
Give your agent the ability to write and run Python and JavaScript code, in a secure sandbox.
Every execution happens inside its own WebAssembly sandbox with strict resource limits. No file system access, no risk to your host system.
## Tools
| Tool | Description |
|------|-------------|
| `execute_python` | Run Python code in an isolated sandbox |
| `execute_javascript` | Run JavaScript code in an isolated sandbox |
### Example
Ask your agent:
> *"I have monthly revenue of [12400, 15800, 14200, 18900, 21000, 19500]. What's the average and which month grew the most?"*
The agent calls `execute_python` with:
```python
revenue = [12400, 15800, 14200, 18900, 21000, 19500]
avg = sum(revenue) / len(revenue)
growth = [revenue[i] - revenue[i-1] for i in range(1, len(revenue))]
best_month = growth.index(max(growth)) + 2 # +2 for 1-indexed and offset
{"average": round(avg, 2), "best_growth_month": best_month, "growth": max(growth)}
```
→ `{"average": 16966.67, "best_growth_month": 4, "growth": 4700}`
## Setup
Add to your MCP client configuration:
```json
{
"mcpServers": {
"capsule": {
"command": "npx",
"args": ["-y", "@capsule-run/mcp-server"]
}
}
}
```
## How It Works
The server ships two pre-compiled WebAssembly modules: one for Python, one for JavaScript. When a tool is called, the code is executed via `capsule` inside a dedicated Wasm sandbox with:
- **Isolated memory** — each execution gets its own address space
- **CPU/Ram limits** — fuel-metered execution prevents runaway loops
- **No host access** — no filesystem or network unless explicitly allowed
Learn more about [Capsule](https://github.com/capsulerun/capsule).
## Limitations
- **Stateless** — each execution starts from a clean sandbox. There is no shared state between calls. To chain results, pass previous outputs as inputs to the next execution.
- **Python HTTP** — standard networking libraries are not compatible with the Wasm sandbox.
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: execute_javascript for JavaScript code execution and execute_python for Python code execution. There is no overlap or ambiguity between them, as each targets a different programming language in a similar sandbox environment.
Both tools follow a consistent verb_noun naming pattern (execute_javascript and execute_python), using the same verb 'execute' followed by the language name. This makes the naming predictable and easy to understand across the tool set.
With only 2 tools, the server feels thin for a general-purpose code execution server. While it covers two popular languages, the scope suggests potential for more languages (e.g., Ruby, Go) or related operations (e.g., list_sandboxes, kill_execution), making the current count insufficient for broad utility.
The server provides execution capabilities for JavaScript and Python, which are core to its domain of code execution. However, there are notable gaps: no tools for managing sandboxes (e.g., creating, listing, or terminating), handling dependencies, or supporting other common languages, limiting agent workflows to basic execution without lifecycle control.