vmware-sandbox-mcp

Overview Schema Source Related Servers Discussions Admin

sandbox_start

Start long-running or persistent commands in a sandbox and return immediately with a job ID, so servers, watchers, builds, or downloads keep running in the background.

Instructions

Start a command in a sandbox that keeps running in the background, and return at once.

Use this for things that do not finish on their own or take very long: a web server, a database, a watcher, a long build or download. sandbox_run would wait for them and time out. After starting, use sandbox_run for other commands in the same sandbox (for example to talk to the server you started), sandbox_check to see its output and whether it is still running, and sandbox_stop to end it.

The command is run by bash, starting in the home directory, with no keyboard input. A sandbox can have at most 8 background commands running at once. Background commands end when the sandbox is destroyed.

Returns a job_id to pass to sandbox_check and sandbox_stop.

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": {
      "sandbox_id": "<sandbox_id>",
      "command": "<command>"
    },
    "name": "sandbox_start"
  }
}

Input Schema

Name	Required	Description	Default
`command`	Yes
`sandbox_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the execution shell (bash), working directory (home), absence of keyboard input, a hard concurrency cap of 8 background commands, and the lifecycle rule that background commands die with the sandbox. What it omits is failure behavior (e.g., what happens when the 8-job limit is hit or the command fails to launch) and any permission or authentication requirements.

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?

Front-loaded with the core action in the first sentence, then when-to-use, then sibling routing, then execution constraints, then the return value. Every sentence adds information an agent needs; nothing is repeated from the schema or padded.

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?

An output schema exists, yet the description still names the key return value (job_id) and states which siblings consume it, which is more than required. Combined with the concurrency limit and lifecycle disclosure, an agent has everything needed to call this correctly and use the result.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning for `command` (interpreted by bash, runs in the home directory, receives no stdin), but `sandbox_id` is never explained — the agent must infer it identifies an existing sandbox, and there is no hint about where such an id comes from.

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 (start), resource (a command in a sandbox), and the defining behavioral property: it keeps running in the background and returns immediately. It explicitly contrasts with sandbox_run, so the agent can distinguish it from the sibling without opening either schema.

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?

Gives an explicit when-to-use rule ('things that do not finish on their own or take very long') with concrete examples (web server, database, watcher, long build or download) and states why the alternative sandbox_run is wrong here ('would wait for them and time out'). It also routes follow-up work to sandbox_run, sandbox_check, and sandbox_stop by name.

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

Deploy Server