Skip to main content
Glama

container_run

Creates and starts a Docker container from an image in one call. Run detached for background tasks or attached to capture output.

Instructions

Run a container from an image (create and start in one call, like docker run).

Use container_create to prepare a container without starting it, or container_exec to run a command in a container that already exists. With detach=False the call blocks until the container exits and returns its output, so long-running images need detach=True. Created containers are stamped with provenance labels.

Args: command: The command to run in the container name: Name to assign to the container detach: Run in the background and return container info environment: Environment variables, as {"KEY": "value"} or a list of "KEY=value" strings ports: Port mappings, e.g. {'2222/tcp': 3333} volumes: Volumes to mount, as {"/host/path": {"bind": "/in/container", "mode": "rw"}} or a list of "host:container:mode" strings network: Name of the network to attach hostname: Hostname for the container user: Username or UID to run as working_dir: Working directory inside the container entrypoint: Entrypoint to override the image default restart_policy: Restart policy, e.g. {'Name': 'on-failure', 'MaximumRetryCount': 3} labels: Labels to set on the container remove: Remove the container when it exits (only with detach=False) auto_remove: Enable auto-removal of the container on daemon side privileged: Give extended privileges to the container tty: Allocate a pseudo-TTY mem_limit: Memory limit: bytes as an int, or a units string ("100000b", "1000k", "128m", "1g") cpu_count: Number of CPUs extra_kwargs: Additional keyword arguments forwarded to ContainerCollection.run (call docs_lookup(section="containers") for the full accepted set)

Returns: dict | str: The container's full inspect payload when detach=True, else stdout/stderr as a string

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttyNo
nameNo
userNo
imageYes
portsNo
detachNo
labelsNo
removeNo
commandNo
networkNo
volumesNo
hostnameNo
cpu_countNo
mem_limitNo
entrypointNo
privilegedNo
stdin_openNo
auto_removeNo
environmentNo
working_dirNo
extra_kwargsNo
restart_policyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.6
    • changedInput schema / $defs / RestartPolicy / description
      Previous value: -"Restart policy for container_run, mirroring the `docker` module's expected dict shape."New value: +"Restart policy for container_run, mirroring the `docker` module's expected dict shape.\n\nAttributes:\n    Name: the policy name the docker module expects.\n    MaximumRetryCount: how many restarts to attempt, where the policy uses one."
  2. Addedv2.0.0

TDQS

A4.5/5.0
Behavior4/5

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

The annotations only contain readOnlyHint=false and destructiveHint=false, so the description carries most of the behavioral burden. It adds valuable runtime behavior: blocking/returning output with detach=False, returning inspect payloads with detach=True, and stamping containers with provenance labels. It could mention auth/error conditions but these are not common for a local Docker 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?

The description is front-loaded with a one-line purpose, then usage guidance, then a compact Args list, and finally a Returns note. Each parameter gets a single, mostly one-line explanation with examples only for the non-obvious ones. It is long because there are 22 parameters, but it avoids fluff and repetitive phrasing.

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?

Given the complexity of 22 parameters and nested object types, the description covers most usage scenarios with passable guidance and format examples. It also references docs_lookup for extra_kwargs, which helps discover the full set. It misses two parameters (image, stdin_open) and does not elaborate on error cases, but the overall invocation path is clear.

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 description coverage is 0%, so this description is the primary source of parameter meaning. It provides concrete formats and examples for environment, ports, volumes, restart_policy, and mem_limit, and explains extra_kwargs. However, it omits the image and stdin_open parameters, which remain undocumented except for the raw schema.

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 description opens with 'Run a container from an image (create and start in one call, like `docker run`)', which clearly states the verb, resource, and atomic action. It distinguishes the tool from container_create (prepares without starting) and container_exec (runs in an existing container), so an agent can tell them apart 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?

It explicitly instructs when to use alternatives: 'Use container_create to prepare a container without starting it, or container_exec to run a command in a container that already exists.' It also gives conditionally actionable advice about detach: 'long-running images need detach=True', guiding the choice between blocking and background behavior.

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