Skip to main content
Glama

docker/exec

Destructive

Run one command in a running container and return stdout, stderr, and exit code. Ideal for one-off tasks; no TTY or stdin.

Instructions

Runs ONE command inside a running container and returns its stdout, stderr and exit code: no TTY, no stdin, no follow. The highest-risk docker tool: arbitrary code, as the image's user (often root) unless user is set, with its own containers: grant list. Always runs as root at the Docker socket: no privileged argument, refused unless the grant has allowed: true. command is an argv array, not a shell line: ["sh", "-c", "ls /app"] for a shell. A non-zero exit code is not a tool error; read exit_code. timeout (seconds, default 30, capped at 300) is bounded by the worker limit, which is 30 s unless the operator sets timeout_seconds for docker/exec in daemon.yaml: then the answer is timed out after N seconds and the command keeps running in the container. Output is capped at 1 MiB. Text shows Exit code: N and the output; output_format: json returns container, id, command, exit_code, running, stdout, stderr. To read logs use docker/logs, to manage the container docker/manage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNoRun as this user inside the container (name or uid[:gid]); default is the image's user
commandYesargv array, e.g. ["sh", "-c", "ls /app"]
timeoutNoSeconds to wait (default 30, values above 300 are capped at 300); the worker limit (30 s unless raised in daemon.yaml) ends the call first
containerYesContainer name, full ID or ID prefix
working_dirNoWorking directory inside the container
output_formatNojson returns container, id, command, exit_code, running, stdout, stderr; default is text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive/non-readonly/non-idempotent, but the description goes well beyond them: no TTY/stdin/follow, runs as root at the socket, as the image's user unless `user` is set, non-zero exit is not a tool error, timeout interaction with the worker limit and continued execution after timeout, and a 1 MiB output cap. This is exactly the extra behavioral context that matters for a high-risk tool.

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?

Dense and front-loaded: purpose, then risk profile, then argument semantics, then timeout/output behavior, then sibling routing. It is long, but each sentence carries distinct operational information rather than filler.

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 documents the return shape for both text ('Exit code: N' plus output) and json (container, id, command, exit_code, running, stdout, stderr). Combined with risk, timeout and argument semantics, an agent has everything needed to call it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema does not: `command` is an argv array rather than a shell line (with an sh -c example), and `timeout` is bounded by the worker limit which can override it. These nuances materially affect correct invocation.

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+resource+scope ('Runs ONE command inside a running container and returns its stdout, stderr and exit code') and immediately narrows it ('no TTY, no stdin, no follow'). It names the siblings it is not (docker/logs, docker/manage), so an agent can route correctly without opening schemas.

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?

Explicitly routes to alternatives ('To read logs use docker/logs, to manage the container docker/manage') and states the conditions for use: refused unless the grant has allowed: true, and the grant-list requirement. Both when-to-use and when-not-to-use are covered.

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