Skip to main content
Glama

Create sandbox

sandbox_create
Destructive

Creates a billed Firecracker microVM in a chosen project for isolated code execution and returns its ID, with template, size, snapshot, volume, and lifetime options.

Instructions

Create a sandbox (a Firecracker microVM) in an explicit project. Uses billed cloud resources and returns its ID. Defaults: template interpreter, size small (2 vCPU / 4 GB), a 5-minute lifetime; expiry deletes its files unless a volume is attached. Other templates: base, codex, claude, opencode, pi, prime, desktop (the server checks the name). Sizes: small, medium (4 vCPU / 8 GB), large (8 vCPU / 16 GB). Pass snapshotId to start from a saved snapshot (it keeps the snapshot's size, so leave size out) and volume to mount a persistent volume. No host files, environment variables, or API key are copied into it. Get the user's approval before creating it; do not retry an uncertain response blindly.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "confirm": "<confirm>"
    },
    "name": "sandbox_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoDefault small; not with snapshotId
regionNoRegion code (region_list); default us-east-1, or the volume's or snapshot's region
volumeNoPersistent volume name or ID in the same project (volume_list)
confirmYes
projectYes
templateNoTemplate name; default interpreter
lifetimeMsNoLifetime in ms, 60,000 to 86,400,000 (a day); extend later with sandbox_set_timeout
snapshotIdNoSnapshot ID from sandbox_snapshot or sandbox_snapshot_list

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.3
    • addedInput schema / properties / lifetimeMs / description
      Added value: +"Lifetime in ms, 60,000 to 86,400,000 (a day); extend later with sandbox_set_timeout"
    • changedInput schema / properties / lifetimeMs / maximum
      Previous value: -3600000New value: +86400000
    • addedInput schema / properties / region
      Added value: +{
      +  "description": "Region code (region_list); default us-east-1, or the volume's or snapshot's region",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / size
      Added value: +{
      +  "description": "Default small; not with snapshotId",
      +  "enum": [
      +    "small",
      +    "medium",
      +    "large"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / snapshotId
      Added value: +{
      +  "description": "Snapshot ID from sandbox_snapshot or sandbox_snapshot_list",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "pattern": "^[a-zA-Z0-9_-]+$",
      +  "type": "string"
      +}
    • addedInput schema / properties / template
      Added value: +{
      +  "description": "Template name; default interpreter",
      +  "pattern": "^[a-z0-9][a-z0-9-]{0,62}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / volume
      Added value: +{
      +  "description": "Persistent volume name or ID in the same project (volume_list)",
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Addedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: billed cloud resources, the 5-minute default lifetime and that expiry deletes files unless a volume is attached, that no host files/env vars/API key are copied in, and that the server validates template names. The destructiveHint=true annotation is corroborated and explained by the lifetime-deletion behavior.

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

Conciseness4/5

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

Front-loaded with definition, defaults, and options in a compact sequence; every sentence carries information. It is dense to the point of being slightly packed (parenthetical template list mid-sentence), but there is no filler.

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

Completeness4/5

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

For an 8-parameter, non-idempotent, billed mutation with no output schema, it covers cost, lifetime, deletion semantics, isolation, approval gating, and return value (the ID). Minor gaps remain: it does not describe behavior on name conflicts or how a failed creation affects volume/snapshot state.

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

Parameters5/5

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

Adds meaning the schema alone lacks: the enumerated valid template names, the meaning of each size in vCPU/RAM, the interaction rule that snapshotId keeps the snapshot's size so size must be omitted, and that region defaults to the volume's or snapshot's region. Schema coverage is 75%, and the description fills the remaining gaps rather than restating enum values.

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?

States a specific verb and resource and immediately defines the resource: "Create a sandbox (a Firecracker microVM) in an explicit project." It also distinguishes it from sibling creation paths by noting snapshotId starts from a saved snapshot (as opposed to sandbox_snapshot/sandbox_fork) and that it returns an ID.

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?

Gives concrete selection guidance: pass snapshotId to start from a snapshot (and then leave size out), pass volume to mount a persistent volume, plus defaults for template and size. It also states a real precondition ("Get the user's approval before creating it") and a caution ("do not retry an uncertain response blindly"). It does not explicitly name sibling alternatives such as sandbox_fork for cloning an existing sandbox, which keeps it from a 5.

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