Skip to main content
Glama

Create Experiment

create_experiment

Run risky commands in a disposable, isolated Docker sandbox with a snapshot copy of your project, keeping your host untouched. Test builds, installs, and migrations safely with enforced limits.

Instructions

Create a disposable, isolated environment and copy a project into it.

USE THIS when you are about to do something you should not do on the developer's machine: install dependencies, run a build or a migration, try an upgrade, run unfamiliar code, or explore a fix you are not sure about. Reach for it before the risky step, not after.

The project is SNAPSHOT-COPIED into the sandbox. Files you change inside never propagate back; the developer's working tree is untouched by construction. Secrets (.env files, keys, credential directories) are withheld from the copy, as are node_modules and other build output.

RETURNS an experiment_id plus the isolation actually applied -- read the warnings field, which tells you where your request was clamped.

SAFETY: network is disabled unless you ask for it; no host environment variable is passed unless you name it, and credential-shaped names are refused even then; CPU, memory, PIDs and wall-clock are capped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutNoDefault per-command wall-clock limit in seconds.
cpu_limitNoCPU cores. Clamped.
objectiveNoWhat you are trying to find out. Shows up in the report.
base_imageNoDocker image to run in, e.g. 'node:22-slim', 'python:3.12-slim'. Choose the runtime the experiment is actually about.
memory_limitNoMemory, e.g. '2GB'. Clamped.
network_modeNo'none' (default, no network at all), 'restricted' (egress on a private bridge, no reach to other sandboxes), or 'enabled'. Use 'restricted' when you must install packages.
project_pathNoAbsolute path to the project to copy in. Omit for an empty sandbox. Must not be a home or system directory.
mount_strategyNo'COPY_TO_SANDBOX' (default, safest) or 'READ_ONLY_BIND_MOUNT' for a large repo you only need to read. Writable host mounts do not exist.
setup_commandsNoCommands to run once the sandbox is ready, in order. Stops at the first failure and reports it.
environment_allowlistNoEnvironment variables to expose. 'NAME' forwards the host's value; 'NAME=value' injects a literal. Nothing else crosses the boundary.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
warningsNo
base_imageYes
setup_jobsNo
files_copiedNo
network_modeYesHow much of the network the sandbox can see. ``NONE`` -- no interfaces at all. The default. ``RESTRICTED`` -- an isolated bridge network shared by nothing else; egress works, but the sandbox cannot reach other sandboxes or the host's service ports. ``ENABLED`` -- the daemon's default bridge. Full egress.
project_nameYes
experiment_idYes
mount_strategyYesHow the project reaches the sandbox. ``COPY_TO_SANDBOX`` -- snapshot the tree, hand the copy to the container. The host tree is unreachable. ``READ_ONLY_BIND_MOUNT`` -- bind the real tree read-only. Faster on large repos; writes to it fail by construction.
workspace_pathYes
resource_limitsYes
environment_passedNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the behavioral disclosure burden. It explains that the project is snapshot-copied, changes never propagate back, secrets and build output are withheld, network is disabled by default, environment variables are restricted, and CPU/memory/PIDs/wall-clock are capped. It also warns about the returned warnings field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but well-structured and front-loaded: purpose, usage, isolation behavior, return value, and safety. Every sentence earns its place and the use of short labeled sections ('RETURNS', 'SAFETY') makes the content easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 10-parameter tool with no annotations, this description is exceptionally complete. It covers purpose, usage timing, data-flow guarantees, security boundaries, returned values, and limitations. The output schema exists, so return details are already structured, and the description still adds the key warning-field guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter. The description adds valuable behavioral semantics beyond the schema: credential-shaped environment variable names are refused, resource limits are clamped/capped, and network is off unless requested. This extra context enhances correct parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create a disposable, isolated environment and copy a project into it.' It clearly distinguishes this creation tool from its siblings by focusing on setup and isolation, and the later 'USE THIS when' section reinforces what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit, concrete usage guidance: use this before risky actions like installing dependencies, running builds, migrations, upgrades, or unfamiliar code. It strongly communicates the when, but does not explicitly name alternative tools or state when not to use it, so it falls just short of a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AbhiteshPundir/sandbox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server