vmware-sandbox-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VMSANDBOX_BASE_VMX | Yes | Full path of the base VM's .vmx file. | |
| VMSANDBOX_SNAPSHOT | Yes | Name of the powered-off snapshot to clone from. | |
| VMSANDBOX_WEB_VNET | No | Dedicated host-only VMware network for web sandboxes, for example VMnet9. Setting it together with VMSANDBOX_WEB_PROXY_HOST switches web mode on. | |
| VMSANDBOX_AUDIT_LOG | No | File the audit log is appended to. Defaults to audit.jsonl in the clones folder. | audit.jsonl |
| VMSANDBOX_WEB_PORTS | No | Destination ports web sandboxes may connect to. | 80,443 |
| VMSANDBOX_CLONES_DIR | Yes | Folder where sandboxes live. Created if missing. Use it for nothing else. | |
| VMSANDBOX_GUEST_USER | Yes | Login name inside the base VM. | |
| VMSANDBOX_VMRUN_PATH | No | Full path of vmrun if it is not in the standard location. Auto-detected by default. | |
| VMSANDBOX_REMOTE_INPUT | No | Set to on to enable the keyboard and mouse tools. Off by default. | off |
| VMSANDBOX_TRANSFER_DIR | Yes | The only host folder copy_in / copy_out can read or write. Created if missing. | |
| VMSANDBOX_MAX_SANDBOXES | No | Maximum sandboxes existing at once. | 3 |
| VMSANDBOX_GUEST_PASSWORD | Yes | Password for the guest login. | |
| VMSANDBOX_WEB_PROXY_HOST | No | This computer's IP address on the web network. The proxy listens only there. | |
| VMSANDBOX_WEB_PROXY_PORT | No | Port the web proxy listens on. | 3128 |
| VMSANDBOX_MAX_AGE_MINUTES | No | Sandboxes older than this are destroyed automatically. | 120 |
| VMSANDBOX_BOOT_TIMEOUT_SECONDS | No | How long sandbox_create waits for the guest to become ready. | 180 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Disposable Linux computers (sandboxes). Create one, use it, then destroy it. Nothing done inside a sandbox affects the user's real computer.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sandbox_createA | Create a fresh, disposable Linux computer (a "sandbox") and wait until it is ready to use. Use this before running untrusted code, installing packages, or trying anything you would not want to do on the user's real computer. Every sandbox starts from the same clean state and is completely separate from the user's machine and from other sandboxes. network: "none" (default) gives the sandbox no network at all. Choose another mode only when the task needs to download something:
Takes up to a few minutes. Returns the sandbox_id to pass to the other sandbox tools. Destroy the sandbox with sandbox_destroy when you are finished. |
| sandbox_runA | Run a shell command inside a sandbox and return what it printed. Use this to execute code, install packages, inspect files, or do anything else on the
sandbox computer. The command is run by bash, so pipes, redirects, && and multi-line
scripts all work. Each call starts in the home directory with a fresh shell: files
persist between calls, but timeout_seconds: how long the command may run (1 to 3600, default 60). When the limit is reached the command is killed and timed_out is true. Returns stdout, stderr, exit_code (0 means success) and timed_out. Very long output is cut at 1 MB; stdout_truncated / stderr_truncated say when that happened. |
| sandbox_startA | 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. |
| sandbox_checkA | Look at a background command started with sandbox_start: is it still running, and what has it printed? Returns status ("running", "exited" when it ended by itself, or "stopped" when it was killed), exit_code (only when status is "exited"; 0 means success), and stdout and stderr collected so far. If the output is longer than about 1 MB only the newest part is returned, and stdout_truncated / stderr_truncated say so. Calling this does not affect the command; call it again later to see newer output. |
| sandbox_stopA | Stop a background command started with sandbox_start, together with any programs it started. Use this when you no longer need the command, or to free one of the 8 background slots. Its output stays available through sandbox_check afterwards. Returns a short confirmation, which also says if the command had already ended. |
| sandbox_copy_inA | Copy a file or a whole folder from the user's computer into a sandbox. Use this to give the sandbox something to work on (a script, a dataset, a project folder). Only things inside the user's designated transfer folder can be copied; nothing else on the user's computer is reachable. host_path: the file or folder to copy, relative to the transfer folder (for example "data/input.csv" or "myproject"). Paths that leave the transfer folder are rejected. guest_path: full destination path inside the sandbox. For a file, the path of the file itself (for example "/home/debian/input.csv"); its folder must already exist. For a folder, the path the folder should have (for example "/home/debian/myproject"); it is created if missing, and the folder's contents are placed inside it. Folders are copied with everything in them. Files arrive without the executable flag (use chmod +x if needed). A folder that contains links is refused. Returns a short confirmation with the number of files and the size. |
| sandbox_copy_outA | Copy a file or a whole folder from a sandbox to the user's computer. Use this to save results (a report, a built program, a log, an output folder) before destroying the sandbox, since everything inside a sandbox is lost when it is destroyed. Things can only be written inside the user's designated transfer folder. guest_path: full path of the file or folder inside the sandbox (for example "/home/debian/out.txt" or "/home/debian/build"). host_path: where to save it, relative to the transfer folder (for example "results/out.txt" or "results/build"). Missing folders are created; existing files with the same names are replaced. Paths that leave the transfer folder are rejected. When copying a folder, its contents are placed inside host_path. Links and files whose names are not valid on the user's computer are left out; the reply says how many. Returns the full path where it was saved, the number of files and the size. |
| sandbox_screenshotA | Take a picture of what is currently on a sandbox's screen. Use this to see things that have no text output: a graphical program, a boot or error screen, or to check what the sandbox is displaying when a command seems stuck. For the output of commands, sandbox_run is faster and more precise. Returns a PNG image of the sandbox's display at this moment. Positions in this image, counted in pixels from its top-left corner, are what sandbox_click expects. |
| sandbox_clickA | Click the mouse at a position on a sandbox's screen. Use this to operate graphical programs: press buttons, open menus, focus a text field before typing. First take a sandbox_screenshot, find the thing to click, and pass its position: x pixels from the left edge and y pixels from the top edge of that image. Take another screenshot afterwards to see the result; screens need a moment to react. button: "left" (default), "right" or "middle". double: true for a double-click. Only works if the user has switched keyboard and mouse input on; the error says so otherwise. For anything that can be done with a command, sandbox_run is faster and more reliable. |
| sandbox_typeA | Type text on a sandbox's keyboard, as if a person typed it. The text goes to whatever has keyboard focus on the sandbox's screen, so click the right field first (sandbox_click) and check with sandbox_screenshot. A line break in the text presses Enter, a tab presses Tab. Only plain English keyboard characters can be typed (letters, digits, common symbols), at most 10,000 at a time. For shortcuts and special keys use sandbox_key. |
| sandbox_keyA | Press a single key or a keyboard shortcut on a sandbox's keyboard. keys: a key name, or modifiers and a key joined with "+". Examples: "Return", "Escape", "Tab", "ctrl+c", "ctrl+alt+t", "alt+F4", "shift+Tab", "super" (opens the desktop's application search). Modifiers: ctrl, alt, shift, super. Key names: Return, Escape, Tab, Backspace, Delete, Space, Up, Down, Left, Right, Home, End, PageUp, PageDown, Insert, F1 to F12, or any single character. |
| sandbox_destroyA | Shut down a sandbox and permanently delete it and everything inside it. Use this as soon as you no longer need a sandbox; only a few can exist at once. Copy out any files you want to keep first, because this cannot be undone. Returns a short confirmation. |
| sandbox_listA | List the sandboxes that currently exist. Use this to find a sandbox_id you lost track of, or to check whether old sandboxes should be destroyed. Returns one entry per sandbox with its sandbox_id, network mode ("none" or "nat"), status, and age in seconds. Returns an empty list if there are none. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool maps to a distinct action in the sandbox lifecycle: foreground execution (sandbox_run) vs background jobs (sandbox_start/sandbox_check/sandbox_stop) are explicitly contrasted in the descriptions, and the GUI trio (screenshot/click/type/key) has clear boundaries. File transfer directions (copy_in vs copy_out) and lifecycle ops (create/list/destroy) are unambiguous.
Every tool is snake_case with the same 'sandbox_' prefix followed by a clear verb or verb_noun (create, destroy, list, run, start, stop, check, copy_in, copy_out, click, type, key). No mixed conventions or stray casing.
13 tools sit squarely in the well-scoped 3-15 range. Each tool covers a necessary facet (lifecycle, command execution, background job handling, file transfer, GUI control) without redundancy.
Core lifecycle, execution, background job management, bidirectional file transfer, and GUI interaction are all covered, so agents can complete typical workflows. Minor gaps exist—no scroll/drag clipboard actions, no way to change a sandbox's network mode after creation, and file introspection relies on shell commands—but these are workable around.