agent-sandbox-platform
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_TOKEN | No | Authentication gate. When set, enforces enterprise Bearer token validation for all sandbox endpoints; when unset or empty, defaults to 'valid-token' for local development. | |
| DOCKER_HOST | No | Container engine host/socket (defaults to the default Docker socket at /var/run/docker.sock). When set, launches isolated ephemeral Alpine containers; when unset or empty, activates behavioral policy simulation if the Docker daemon is unavailable. | |
| GEMINI_API_KEY | No | Agent tool client. When set, connects the live autonomous agent loop to Google Gemini as the external model provider; when unset or empty, runs deterministic diagnostic test scripts against the sandbox APIs. | |
| OPENAI_API_KEY | No | Agent tool client. When set, connects the live autonomous agent loop to OpenAI as the external model provider; when unset or empty, runs deterministic diagnostic test scripts against the sandbox APIs. | |
| POLICY_BLOCKED_TOKENS | No | Policy enforcement. Comma-separated custom organizational command blacklist. When unset or empty, enforces the default safety tokens (rm, curl, wget, nc, bash). |
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 |
|---|---|
| execute_in_sandboxA | Executes untrusted shell commands or code payloads inside an isolated, non-root ephemeral Docker container with strict CPU/memory limits and timeout enforcement. |
| validate_sandbox_policyB | Evaluates a proposed command against security policy rules (e.g. denylist patterns, egress boundaries) before execution. |
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 2 tools
The two tools have clearly distinct purposes: one performs a pre-execution policy check and the other actually runs the command in an isolated container. An agent can readily tell whether it needs validation or execution, and the descriptions reinforce the boundary.
Both names are snake_case and verb-led, giving a predictable feel. The patterns differ slightly (validate_noun vs. execute_in_noun), but they remain readable and consistent enough for reliable selection.
Two tools is thin for a platform that implies sandbox lifecycle management beyond validation and execution. The pair covers the minimal workflow, but the surface feels borderline sparse rather than well-scoped.
Core actions—policy validation and isolated execution—are present, but obvious lifecycle operations such as sandbox status, cancellation, cleanup, or policy management are absent. Agents can work around some gaps because containers are ephemeral, but the surface is not fully complete for a sandbox platform.