Skip to main content
Glama
Sign In

EQVPS — VPS and code sandboxes for AI agents

by io.github.Poiuyhje
OverviewDiscussionsAdmin

Create a code sandbox

create_sandbox
Destructive

Start an isolated Firecracker microVM sandbox (ready in about 1 s; Linux with Python 3.12 + pip, Node.js 22 + npm, bash, git and curl; internet egress allowed so pip/npm install and git clone work; no inbound ports, SMTP blocked). mode: "ephemeral" (default — billed per second, minimum 60 s, auto-deleted after idle_timeout s of inactivity, default 300, max lifetime ttl up to 24 h) or "persistent" (billed per started hour, a month costs at most 730 h minus 25%; survives host maintenance; max ttl 30 days). tariff (default small): micro 0.25 vCPU/512 MB RAM/3 GB disk $0.0165/h · small 0.5 vCPU/1 GB RAM/5 GB disk $0.033/h · standard 1 vCPU/2 GB RAM/10 GB disk $0.066/h · plus 2 vCPU/4 GB RAM/15 GB disk $0.132/h · pro 4 vCPU/8 GB RAM/20 GB disk $0.264/h · max 8 vCPU/16 GB RAM/40 GB disk $0.528/h (pick plus or bigger for heavy pip installs such as torch, builds or data work). Headless browsers (Chromium via Playwright/Puppeteer) need standard or bigger — micro/small do not have enough RAM. If the host is busy the call fails with 503 capacity (Retry-After) — retry or choose a smaller tariff. Charged from the same prepaid balance as VPS (no subscription). Empty balance → 402 insufficient_balance (top up with topup_balance). If the balance runs out later, persistent sandboxes are paused (memory+disk snapshot, not billed) and resume automatically after a top-up; paused snapshots are deleted after 14 days. The response has state: "running" and ready: true once you can exec (usually immediately); if it says starting, call get_sandbox after 1-2 s. Always kill_sandbox when done. Requires: token + balance (billed per second from the prepaid balance, from $0.0165/h on micro; minimum 60 s per sandbox). Typical errors: 402 insufficient_balance → topup_balance; 503 capacity → retry or smaller tariff.

Input Schema

NameRequiredDescriptionDefault
envNoOptional. Environment variables for every command and code run in this sandbox, e.g. {"OPENAI_API_KEY": "sk-..."}. Stored encrypted; responses show only the names (env_keys). Up to 64 variables, 64 KB in total.
ttlNoOptional. Maximum lifetime in seconds (ephemeral up to 86400, persistent up to 2592000).
modeNoOptional. "ephemeral" (default: billed per second, minimum 60 s, auto-deleted when idle) or "persistent" (billed per started hour, kept up to 30 days).
tariffNoOptional. Tariff: micro | small | standard | plus | pro | max (see sandbox_pricing). Default "small"; e.g. "plus" for heavy pip installs.
idle_timeoutNoOptional. Seconds of inactivity before an ephemeral sandbox is deleted (default 300, max 3600). 0 = none (persistent only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / env / description
      Previous value: -"Environment variables for every command and code run in this sandbox, e.g. {\"OPENAI_API_KEY\": \"sk-...\"}. Stored encrypted; responses show only the names (env_keys). Up to 64 variables, 64 KB in total."New value: +"Optional. Environment variables for every command and code run in this sandbox, e.g. {\"OPENAI_API_KEY\": \"sk-...\"}. Stored encrypted; responses show only the names (env_keys). Up to 64 variables, 64 KB in total."
    • changedInput schema / properties / idle_timeout / description
      Previous value: -"Seconds of inactivity before an ephemeral sandbox is deleted (default 300, max 3600). 0 = none (persistent only)."New value: +"Optional. Seconds of inactivity before an ephemeral sandbox is deleted (default 300, max 3600). 0 = none (persistent only)."
    • addedInput schema / properties / mode / description
      Added value: +"Optional. \"ephemeral\" (default: billed per second, minimum 60 s, auto-deleted when idle) or \"persistent\" (billed per started hour, kept up to 30 days)."
    • changedInput schema / properties / tariff / description
      Previous value: -"Tariff: micro | small | standard | plus | pro | max (see sandbox_pricing)."New value: +"Optional. Tariff: micro | small | standard | plus | pro | max (see sandbox_pricing). Default \"small\"; e.g. \"plus\" for heavy pip installs."
    • changedInput schema / properties / ttl / description
      Previous value: -"Maximum lifetime in seconds (ephemeral up to 86400, persistent up to 2592000)."New value: +"Optional. Maximum lifetime in seconds (ephemeral up to 86400, persistent up to 2592000)."
  2. Changed1 schema field changed
    • addedInput schema / properties / env
      Added value: +{
+  "additionalProperties": {
+    "maxLength": 32768,
+    "type": "string"
+  },
+  "description": "Environment variables for every command and code run in this sandbox, e.g. {\"OPENAI_API_KEY\": \"sk-...\"}. Stored encrypted; responses show only the names (env_keys). Up to 64 variables, 64 KB in total.",
+  "propertyNames": {
+    "pattern": "^[A-Za-z_][A-Za-z0-9_]{0,127}$"
+  },
+  "type": "object"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / tariff / description
      Added value: +"Tariff: micro | small | standard | plus | pro | max (see sandbox_pricing)."
    • changedInput schema / properties / tariff / enum
      Previous value: -[
-  "micro",
-  "small",
-  "std"
-]New value: +[
+  "micro",
+  "small",
+  "standard",
+  "plus",
+  "pro",
+  "max"
+]
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say destructive/non-idempotent/non-readonly; the description goes far beyond by disclosing billing models per mode, the 60 s minimum, auto-deletion after idle_timeout, persistent pause-on-empty-balance with 14-day snapshot retention, capacity failures, and auth/balance prerequisites. That is exactly the lifecycle and cost context an agent needs before committing.

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 what the sandbox is, then mode, then tariff, then failure handling – a sensible order with no filler. It loses a point for repetition: the price floor, minimum 60 s, prepaid-balance note and 402 error are each stated twice, and the trailing 'Requires/Typical errors' recap duplicates earlier sentences.

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?

No output schema exists, yet the description explains the response shape (state/ready and the 'starting' case), all error paths, cost implications and cleanup obligations. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is already 100%, so 3 is the baseline, but the description adds real semantics: per-second vs per-hour billing, ttl caps by mode, idle_timeout defaults and its persistent-only exemption, and a full tariff table with vCPU/RAM/disk and hourly prices tied to workload types. This meaningfully exceeds the schema text.

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?

Opens with a specific verb and resource: 'Start an isolated Firecracker microVM sandbox', plus runtime contents (Linux, Python 3.12, Node 22, git, curl) and network posture. It is unmistakably distinct from get_sandbox, list_sandboxes, kill_sandbox and run_code.

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 follow-up routing: call get_sandbox if state is 'starting', 'Always kill_sandbox when done', topup_balance on 402, retry-or-smaller-tariff on 503 capacity. It also advises which tariff to pick for heavy pip installs and headless browsers, though it never explicitly states when not to create a sandbox (e.g. versus reusing an existing one).

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

All EQVPS — VPS and code sandboxes for AI agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources