Skip to main content
Glama

compose_run

Run a one-off command on a Docker Compose service. Executes a command inside a service container and returns stdout, stderr, and return code.

Instructions

Run a one-off command against a compose service.

Always passes -T (no TTY under MCP). Defaults to detached with --rm so the call returns promptly.

args: service - Service name from the compose file command - Command + args to run (exec-form; no shell unless you invoke one) project_dir - Dir with the compose file (default: server cwd) files - Explicit compose file paths (repeatable, -f) project_name - Compose project name override detach - Run detached (default True) rm - Remove the container after the run (default True) no_deps - Don't start linked services workdir - Working directory inside the container user - User to run as inside the container (uid or name) env - Environment variables to set inside the container name - Optional container name timeout_seconds - Subprocess timeout (default 600s) returns: dict - {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rmNo
envNo
nameNo
userNo
filesNo
detachNo
commandNo
no_depsNo
serviceYes
workdirNo
project_dirNo
project_nameNo
timeout_secondsNo
Behavior5/5

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

Annotations only indicate not read-only and not destructive. The description adds significant value by disclosing that it passes -T, defaults to detached and --rm, and describes return dict. This goes beyond annotations, giving clear behavioral expectations.

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?

Well-structured with purpose sentence, behavioral notes, then parameter list. Some parameter descriptions are redundant with names (e.g., 'name - Optional container name'), but overall efficient and front-loaded.

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?

With 13 parameters, 1 required, and no output schema, the description covers return format and parameter semantics comprehensively. It also mentions behavioral defaults (detached, rm, timeout), making it self-sufficient 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 description coverage is 0%, so the description fully compensates. It explains each parameter's purpose beyond types and defaults, e.g., command is exec-form, files as repeatable -f, timeout in seconds. This is essential for correct usage.

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 clearly states 'Run a one-off command against a compose service,' specifying the verb and resource. It distinguishes from siblings like compose_exec (attached) and container_run (standalone) by emphasizing compose context and defaults like detached and auto-removal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context on behavior (always -T, detached with --rm) but does not explicitly contrast with alternatives or state when not to use. Implies usage for one-off commands but lacks explicit exclusion guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/L337-org/docker-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server