wasmer-sandbox-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for the Edge server. Falls back to FASTMCP_PORT, then 8000. | 8000 |
| DB_HOST | Yes | The database host for the Edge Postgres connection. | |
| DB_PORT | Yes | The database port for the Edge Postgres connection. | |
| DB_USER | Yes | The database user for the Edge Postgres connection. | |
| DB_DATABASE | Yes | The database name for the Edge Postgres connection. | |
| DB_PASSWORD | Yes | The database password for the Edge Postgres connection. | |
| FASTMCP_PORT | No | Fallback port if PORT is not set. | 8000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_pythonA | Run Python code inside an isolated Wasmer sandbox and get back its output. Use it to execute code you do not want touching this machine: untrusted snippets,
experiments, quick calculations, anything with side effects you would rather contain.
The sandbox is long-lived: files written and packages installed by earlier calls are
still there, and anything this code writes stays for the next one. Call
|
| run_commandA | Run any command available inside the Wasmer sandbox, with arguments. Use it for non-Python work in the sandbox — a shell utility, or a binary that
The sandbox is long-lived, so this command sees files and packages left by earlier
calls, and its own side effects persist until |
| write_sandbox_fileA | Write a text file inside the sandbox, creating parent directories as needed. Use it to put a script, a fixture or input data where sandboxed code can read it —
|
| read_sandbox_fileA | Read a text file from inside the sandbox. Use it to collect a file that sandboxed code produced, or to check what an earlier
|
| list_sandbox_dirA | List the contents of a directory inside the sandbox. Use it to find out what is actually there before reading or running something —
especially after |
| install_sandbox_packageA | Install a Wasmer registry package into the sandbox and report the commands it adds. Use it to get a tool the sandbox does not already have — the guest starts with only
Python. |
| get_sandbox_infoA | Report whether the sandboxes are warm, and what they are running. Use it when a call came back |
| reset_sandboxA | Throw away the sandbox's accumulated state and start a fresh one. Use it when earlier files, installed packages or environment changes are getting in the
way, or when a sandbox is behaving oddly. Pass |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools are sharply distinguished (file read/write/list, package install, reset, info). The only potential confusion is run_python vs run_command, since run_command could also invoke Python, but the descriptions draw a clear boundary by directing run_command to non-Python work.
All eight tools follow a consistent snake_case verb_noun pattern (run_, get_, write_, read_, list_, install_, reset_). The run_ versus sandbox_ prefixes correspond to a meaningful semantic split between execution and sandbox management, so there is no real inconsistency.
Eight tools is well within the ideal 3-15 range and maps cleanly to the server's purpose: two executors, three filesystem operations, package installation, state inspection, and reset. Each tool earns its place with no redundant entries.
The domain — isolated code execution with persistent sandbox state — is well covered: execute, read/write/list files, install packages, inspect, and reset. The only minor gap is the lack of a dedicated file removal tool, but agents can work around it via run_command('rm', ...) or reset_sandbox.