Safe Code Sandbox
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_runA | Run Python code in a locked-down, throwaway container. The container has no network access, no access to any host directory, and does not run as root. It is deleted when the run ends. Returns a run_id immediately; the code is still running. Poll get_result with that id to collect the output. code: the program to execute, placed at main.py in the workspace. files: optional extra input files, as relative paths and contents. limits: optional memory_mb, timeout_seconds and cpus. Defaults are {default_mem} MB and {default_timeout} seconds; the ceilings are {max_mem} MB and {max_timeout} seconds. Asking for more than a ceiling is rejected rather than silently reduced. |
| get_resultA | Collect the result of a run, or find out it is still going. While the run is in progress this returns status "running". Once it has finished it returns the full report: status, exit code, stdout, stderr and how long it took. A status of "timed_out" or "out_of_memory" means the code hit a limit rather than crashing, so retrying with a larger budget may help. |
| stop_runA | Cancel a run in progress, killing and deleting its container. Safe to call on a run that has already finished; it reports the status it ended with instead of failing. |
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 3 tools
Each tool has a clearly distinct role in the run lifecycle: start_run launches execution, get_result polls or collects output, and stop_run cancels. There is little risk of confusing one for another, even though get_result and stop_run both report status in some cases.
All three tools follow a consistent verb_noun pattern: start_run, get_result, stop_run. The naming is predictable and readable.
Three tools are well-scoped for an asynchronous sandbox execution model: launch, poll, and cancel. Each tool earns its place without unnecessary surface area.
The core lifecycle is covered: start, poll for results, and cancel. Minor gaps include no list_runs or explicit artifact/output-file retrieval beyond stdout and stderr, but these are workable for the stated purpose.