tiny-agent-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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_codeA | Run code without network or host mounts and return bounded stdout, stderr, and status. The timeout may be 1-30 seconds. Output is truncated at the operator-controlled limit. Images must already exist locally; this tool never pulls an image on the agent's behalf. |
| sandbox_statusA | Report Docker daemon readiness and any missing allowlisted runtime images. |
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 serve clearly distinct purposes: run_code executes code while sandbox_status reports environment readiness. There is no meaningful overlap between them, so an agent can easily distinguish which to use.
Both tools follow a consistent verb_noun pattern: run_code and sandbox_status. The naming style is uniform snake_case with clear, descriptive verbs and nouns.
With only 2 tools, the surface feels thin for a sandbox server that presumably supports code execution. A richer surface might include file operations, image management, or environment configuration, but for a narrowly-scoped execution sandbox two tools can be reasonable.
The core execute-and-check lifecycle is covered: run code and check readiness. However, there are notable gaps such as no image listing, no stop/cleanup of sandboxes, and no way to provision or configure runtimes beyond status reporting.