Purgatory (p7y)
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ALLOWED_RUNTIMES | No | Where sysbox is installed, sandboxes run without a privileged container; without it they fall back to the privileged `dind`, which suits a team that trusts each other, not hostile code. On a shared server install sysbox and set `ALLOWED_RUNTIMES=sysbox`. | dind |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| who_am_iC | Who am I HTTP GET /me |
| list_runtimesA | List the runtimes new sandboxes may use (how a sandbox runs: dind, sysbox; ALLOWED_RUNTIMES) HTTP GET /runtimes |
| list_sandboxesB | List all sandboxes HTTP GET /sandboxes |
| create_sandboxC | Create sandbox HTTP POST /sandboxes |
| archive_sandboxA | Archive sandbox Stops the sandbox, saves its volumes (tar.gz) and config under opt/archive//, then removes containers, volumes and the sandbox directory. Nothing is removed if archiving fails. HTTP DELETE /sandboxes/{name} |
| get_sandboxC | Get sandbox details HTTP GET /sandboxes/{name} |
| set_sleep_settingsA | Change sleep settings Changes idle_timeout and/or deep_sleep_after of an existing sandbox. A new idle_timeout recreates only the socat container (a running sandbox's app is unreachable for a few seconds; an asleep one stays asleep) and applies to the next request's Sablier session. A new deep_sleep_after applies immediately. HTTP PATCH /sandboxes/{name} |
| get_sandbox_composeC | The starter stack Purgatorium deployed into the sandbox (compose YAML), secrets masked HTTP GET /sandboxes/{name}/compose |
| deep_sleep_sandboxB | Put a sandbox into deep sleep now (containers and network down, data kept; the next request or start rebuilds it) HTTP POST /sandboxes/{name}/deep-sleep |
| rotate_docker_keysA | New Docker access certificates (enable / rotate) New CA, server and client certificates for the sandbox's Docker API (they carry -docker.); earlier exports stop working. Restarts the sandbox. HTTP POST /sandboxes/{name}/docker-keys |
| delete_sandbox_fileB | Delete a file or a folder (with everything in it) of the sandbox's files HTTP DELETE /sandboxes/{name}/files |
| list_sandbox_filesB | List a folder of the sandbox's files (/root, /home, /srv and /opt, the folders kept over a deep sleep, and the apps' volumes: see list_sandbox_volumes) HTTP GET /sandboxes/{name}/files |
| write_sandbox_fileB | Upload a file into the sandbox's files (replaces one of the same name); its folder must exist HTTP PUT /sandboxes/{name}/files/content |
| create_sandbox_folderC | Create a folder (and its parents) in the sandbox's files HTTP POST /sandboxes/{name}/files/mkdir |
| read_sandbox_fileA | Read a text file of the sandbox's files (UTF-8, up to 1 MB) HTTP GET /sandboxes/{name}/files/text |
| keep_sandbox_awakeA | Start the sleep countdown over For a running sandbox: one request through its router, as any visit would, so it sleeps a full idle timeout from now. Does not wake a sleeping sandbox. HTTP POST /sandboxes/{name}/keep-awake |
| remove_sandbox_mountA | Unmount a host folder from the sandbox (admin) Admin only: removes the host mount on this target (also when HOST_MOUNT_ROOTS is no longer set). The sandbox container is recreated as for adding one. HTTP DELETE /sandboxes/{name}/mounts |
| list_sandbox_mountsA | Host folders mounted into the sandbox The host folders the administrator mounted into the sandbox (host path, target inside the sandbox, readonly). enabled: whether HOST_MOUNT_ROOTS is set on this server; the admin also gets roots, the folders that may be mounted. HTTP GET /sandboxes/{name}/mounts |
| add_sandbox_mountA | Mount a host folder into the sandbox (admin) Admin only, with HOST_MOUNT_ROOTS set: bind-mounts a host folder at or under one of those roots into the sandbox container (its own Docker's apps can bind it from there too). The sandbox's owner gets that folder as root. The sandbox container is recreated: a running sandbox restarts (its apps are unreachable for a few seconds), an asleep one stays asleep, one in deep sleep gets it when it wakes. A host folder that does not exist is an error from Docker, not an empty new folder. HTTP POST /sandboxes/{name}/mounts |
| project_dir_linkA | A single-use link to the project's .p9m folder, with the sandbox's Docker keys Answers a link that works once, for 5 minutes, and the command that unpacks it into the project ( |
| list_sandbox_imagesB | The sandbox's images in the p9m registry, with secret-scan results HTTP GET /sandboxes/{name}/registry |
| delete_sandbox_image_versionB | Delete a version of one of the sandbox's images from the p9m registry The app name is URL-encoded when it has slashes (team%2Fapi for /team/api). An index takes its platform manifests with it; the space comes back at the weekly garbage collection. HTTP DELETE /sandboxes/{name}/registry/{app}/{digest} |
| restart_sandboxC | Restart sandbox HTTP POST /sandboxes/{name}/restart |
| get_sandbox_ssh_keyB | The sandbox's generated SSH private key (for ssh -i) HTTP GET /sandboxes/{name}/ssh-key |
| generate_sandbox_ssh_keyB | Generate the SSH key of a sandbox that has none yet (created with SSH) HTTP POST /sandboxes/{name}/ssh-key |
| wake_sandboxA | Start sandbox Wakes an asleep or deep-sleeping sandbox. At the owner's limit (running sandboxes, slots, or a full server) it answers 409 with |
| sleep_sandboxC | Stop sandbox HTTP POST /sandboxes/{name}/stop |
| list_sandbox_volumesB | The volumes of the apps in the sandbox's own Docker; their files are under each one's path, through the files tools HTTP GET /sandboxes/{name}/volumes |
| sandbox_summaryA | How many sandboxes: allowed, running, asleep, in deep sleep, archived A user: their own, against their quota (SANDBOX_QUOTA; free = how many more they may create). The admin: the whole server, and by_owner per owner. Asleep = stopped (also one that failed to start); archived = deleted sandboxes kept in the archive, not counted against the quota. HTTP GET /sandboxes/summary |
| list_ssh_keysB | Your SSH public keys (they let you into your sandboxes as root) HTTP GET /ssh-keys |
| add_ssh_keyA | Add an SSH public key: it lets you into all your sandboxes with SSH as root HTTP POST /ssh-keys |
| delete_ssh_keyB | Delete one of your SSH keys (it no longer lets you in, at once) HTTP DELETE /ssh-keys/{id} |
| list_templatesA | List the templates (what runs inside a sandbox) HTTP GET /templates |
| get_templateB | A template's compose.yaml as written (to show or edit before a create) HTTP GET /templates/{name} |
| list_tokensB | List personal access tokens (admin: all) HTTP GET /tokens |
| create_tokenC | Create a personal access token (shown once) HTTP POST /tokens |
| revoke_tokenB | Revoke a personal access token HTTP DELETE /tokens/{id} |
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 37 tools
Most tools target clearly distinct resources or actions, and descriptions separate overlapping areas like files vs. volumes vs. mounts and user SSH keys vs. sandbox SSH keys. The main ambiguity is among sandbox lifecycle/state operations (sleep, deep sleep, wake, keep awake, archive, restart), where subtle distinctions create some misselection risk.
The set is predominantly consistent verb_noun snake_case, e.g. create_sandbox, list_sandbox_files, delete_ssh_key. A few names such as project_dir_link, sandbox_summary, and who_am_i break the verb_noun pattern but remain readable.
37 tools is well above the typical ideal range and is heavy for a single MCP server. While the domain is broad and many tools are distinct, the large surface increases selection burden and makes the set unwieldy.
Coverage is broad across sandbox lifecycle, files, mounts, SSH keys, tokens, templates, runtimes, compose, and registry images. Minor-to-moderate gaps exist, such as no unarchive/restore for archived sandboxes, no template write operations, and no file move/rename, but most core workflows are supported.