Skip to main content
Glama

Create Experiment

create_experiment

Create a disposable, isolated sandbox environment with a project copy to safely test risky operations without affecting the developer's machine.

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.9/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 transparency burden. It explains snapshot copying, lack of propagation, secret handling, network defaults, resource caps, mount strategies, and failure behavior in detail.

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 well-structured with clear, front-loaded opening sentences and purposeful paragraph breaks. It is detailed but every sentence adds meaningful information about behavior, safety, or usage, with no filler or tautology.

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?

Given the tool's complexity, the description is remarkably complete. It covers the full lifecycle of creating an experiment, input parameter implications, safety mechanisms, return information, and failure behavior. The presence of an output schema means return values do not need to be exhaustively restated, but the description still usefully mentions experiment_id, warnings, and applied isolation.

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?

The schema already describes every parameter with 100% coverage, so the baseline is 3. The description adds useful contextual semantics beyond the schema, such as recommending 'restricted' network for package installation, warning that writable host mounts do not exist, and noting that credential-shaped environment names are refused.

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 clearly states the tool's purpose: create a disposable, isolated environment and copy a project into it. This distinguishes it from sibling tools like list_experiments, execute_experiment, and get_experiment.

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use this tool, such as 'USE THIS when you are about to do something you should not do on the developer's machine' and provides concrete examples like installing dependencies or running builds. It also clarifies safe defaults and opt-in behaviors.

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/riyasaxena32/sandbox-mcp'

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