Skip to main content
Glama

container_exec

Run commands inside a running Docker container with configurable user, working directory, environment, TTY, and detach options. Returns exit code and output for straightforward automation.

Instructions

Run a command inside a running container (for a compose service, prefer compose_exec).

Security: when any element of cmd is agent-controlled, use an exec-form argv list that does not invoke a shell (e.g. ["python", "-V"], ["ls", path]). A string cmd, or a shell form like ["sh", "-c", template], interprets shell metacharacters in the untrusted parts.

Args: cmd: Command to execute (prefer exec-form argv, no shell, when any element is agent-controlled) tty: Allocate a pseudo-TTY privileged: Run with extended privileges user: User to run the command as detach: Detach from the exec environment: Environment variables, as {"KEY": "value"} or a list of "KEY=value" strings workdir: Working directory inside the container demux: Return stdout and stderr separately

Returns: dict: {"exit_code", "output"}; output is combined stdout+stderr, or a [stdout, stderr] pair with demux=True

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cmdYes
ttyNo
userNo
demuxNo
stdinNo
detachNo
stderrNo
stdoutNo
workdirNo
id_or_nameYes
privilegedNo
environmentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the sparse annotations, the description discloses that shell metacharacters in agent-controlled `cmd` are interpreted and instructs callers to use exec-form argv. It also discloses the return format and the difference between combined and demuxed output, which is valuable behavioral context an agent would not otherwise know.

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?

The description is front-loaded with the core action and alternative, and the Args/Returns sections are structured as compact one-liners. The exec-form security guidance appears twice—once in the security paragraph and again in the `cmd` arg comment—which is slightly redundant but not bloated.

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 a 12-parameter tool with no output schema and sparse annotations, the description covers the essential invocation details: the target container, alternative tool, security constraints, parameter meanings, and return shape. It is not fully complete because `id_or_name`, `stdin`/`stdout`/`stderr`, and side effects of `detach`/`privileged` are not elaborated, but it provides enough for correct use in most cases.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates well by explaining `cmd`, `environment`, `demux`, and other flags in compact terms. However, it omits the required `id_or_name` and does not explain the semantics of `stdin`, `stdout`, or `stderr`, leaving a few parameters underdocumented.

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 line 'Run a command inside a running container' states a specific verb, resource, and precondition. The parenthetical 'for a compose service, prefer `compose_exec`' explicitly distinguishes it from the closest sibling, so an agent can tell it apart without opening other tool definitions.

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 gives an explicit routing rule: for compose services, prefer `compose_exec`, which tells the agent when not to use this tool. It also provides security-driven guidance on choosing exec-form argv versus a shell string, giving clear context for safe invocation.

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

Deploy Server

Other Tools