sandbox-as-a-service-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AAS_API_KEY | Yes | API key from https://sandbox-as-a-service.com/dashboard/keys |
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 |
|---|---|
| create_sandboxA | Create an isolated cloud sandbox — a dedicated virtual machine you can run commands in. Returns once the sandbox is ready. Python 3, Node.js 22, git and a build toolchain are pre-installed. The sandbox is destroyed automatically after timeout_minutes; nothing inside it survives that. Use this before running any code you would not want to run on the local machine. |
| run_commandA | Run a shell command inside a sandbox and wait for it to finish. Returns stdout, stderr and the exit code. The command runs as an unprivileged user in /workspace. A non-zero exit code is returned normally, not as an error. Use this to execute code, install packages, clone repositories or inspect the filesystem. |
| write_fileA | Write a file inside a sandbox. Use this to place a script or input data before running it. Paths are relative to /workspace unless absolute. Content of any kind is safe — it is transferred verbatim, not interpreted by a shell. |
| read_fileA | Read a file back out of a sandbox — an artifact your code produced, a log, a generated report. Use encoding "base64" for binary files such as images. |
| list_filesA | List the contents of a directory in a sandbox, with the type and size of each entry. Defaults to /workspace. Use this to find what your code produced before reading it. |
| expose_portA | Give a server running inside the sandbox a public https URL, so a person can open it in a browser. Use this after starting a web server or dev server in the background. The server only needs to listen on localhost. Returns a URL that works until the sandbox is destroyed. |
| get_sandboxA | Get the current status and details of one sandbox, including when it expires. |
| list_sandboxesA | List the sandboxes on this account, newest first. Use it to find sandboxes you created earlier. |
| extend_sandboxA | Push a sandbox’s expiry further out so long-running work is not cut off. Total lifetime is still capped at 24 hours from creation. |
| destroy_sandboxA | Destroy a sandbox and stop billing for it. Everything inside is lost. Call this as soon as you are finished — do not leave sandboxes running. |
| get_usageA | Show the account’s remaining credit balance and recent sandbox usage. |
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 11 tools
Each tool targets a distinct action and resource: sandbox lifecycle, file operations, command execution, port exposure, and usage lookup are clearly separated. Even similar pairs like list_files and list_sandboxes are disambiguated by both name and description.
All tool names follow a consistent snake_case verb_noun pattern, e.g. create_sandbox, run_command, write_file, destroy_sandbox. There are no mixed conventions, vague verbs, or stylistic deviations.
Eleven tools is a well-scoped size for a sandbox-as-a-service server. Each tool covers a meaningful capability without redundancy or bloat.
The surface covers the full sandbox lifecycle—create, read, list, extend, destroy—plus file operations, command execution, port exposure, and usage tracking. There are no obvious dead ends or missing operations needed for the intended workflow.