Skip to main content
Glama

env_exec

Run shell commands or scripts inside a running virtual machine and retrieve their output and exit codes. Use it to configure, inspect, or directly modify the guest environment.

Instructions

Run a shell command inside an environment and return its exit code and output. The command is one shell string: pipes, redirects, globs and quoting are interpreted by the guest shell, unlike the CLI's terrarium exec, which passes its arguments literally. Which shell that is: /bin/sh on Linux guests; on a Windows guest, the shell recorded for its golden, which is PowerShell for a golden terrarium built and cmd.exe for an older or adopted one, unless terrarium adopt --shell said otherwise. Pass shell (powershell, cmd or sh) to run under a different one, and script instead of command for anything multi-line or heavily quoted - a script reaches the shell on stdin, so nothing in it is re-parsed on the way. The environment must be running. Commands run as a user with passwordless sudo, so this can change or destroy anything inside the guest - the host is not affected. A command that outruns timeout_sec is killed in the guest, with its child processes, and the error says what was killed: nothing is left running where you cannot see it. On a Windows guest an ordinary command runs in session 0, which has no screen: if it opens a window or a dialog it waits there forever and env_screenshot shows nothing. Set desktop to run it in the session a user is logged into instead, where env_screenshot can see what it wants. Only works when the environment's golden has SSH credentials; without them, use env_screenshot, env_type, env_keys and env_click.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesname of the environment to run in
shellNorun under this shell instead of the guest's own: powershell, cmd or sh
scriptNomulti-line script to run instead of command; it reaches the shell on stdin so nothing in it is quoted or split
commandNoshell command to run in the guest; omit when passing script
desktopNoWindows guests only: run in the session a user is logged into, so env_screenshot shows the window or dialog the command opens. Without it a command runs in session 0, which has no screen
timeout_secNoseconds to wait before giving up (default 300)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputYes
exit_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so thoroughly: it warns about passwordless sudo and guest-only destruction, timeout kill behavior with child processes, Windows session 0 limitations, and the required SSH credential precondition. This is exemplary transparency.

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 long but every sentence earns its place, covering purpose, shell semantics, command vs script, security, timeout behavior, Windows desktop mode, and prerequisites. The core action is front-loaded, and the length is justified by the tool's complexity and safety implications.

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?

For a 6-parameter, side-effect-capable tool with platform-specific behavior and sibling alternatives, the description covers all essential decision points: shell choice, script vs command, timeout behavior, desktop mode, SSH requirement, and fallback tools. It is fully actionable for an agent.

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%, but the description still adds real meaning: it explains that command is a single shell string interpreted by the guest shell, script reaches stdin and avoids re-parsing, shell overrides the guest's shell, and desktop affects Windows session visibility. These clarifications materially help an agent choose parameter values correctly.

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 opening sentence states the specific verb and resource: run a shell command inside an environment and return exit code and output. It clearly differentiates from screen-interaction siblings like env_screenshot, env_type, and env_click, and from the CLI's terrarium exec.

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 provides explicit guidance on when to use command vs script, when to pass shell, when to set desktop for Windows guests, and states the SSH-credential prerequisite with named alternatives. This goes well beyond implied usage.

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