Skip to main content
Glama
L337-org

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

compose_up

Start Docker Compose services in detached mode, with options to build images, specify services, and wait for healthy status. Returns CLI output for verification and troubleshooting.

Instructions

Bring up a Docker Compose project, detached.

Always runs detached (-d) so it can't block the server. Use compose_ps to confirm services are running, or wait=True to block until they're healthy. Does not raise on a non-zero CLI exit (a missing compose plugin or a timeout still raises) - inspect returncode/stderr in the result.

Args: project_dir: Dir with the compose file (default: server cwd, copied to the target host if no local plugin; paths verbatim, no shell expansion) files: Explicit compose file paths (repeatable, -f) project_name: Compose project name override services: Specific services to bring up (default: all) build: Build images before starting pull: Pull strategy; omit to use each service's own pull_policy remove_orphans: Remove containers for services not in the compose file wait: Block until services are healthy (adds --wait) timeout_seconds: Subprocess timeout (default 600s)

Returns: dict: {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pullNo
waitNo
buildNo
filesNo
profilesNo
servicesNo
project_dirNo
project_nameNo
remove_orphansNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.5
    • addedInput schema / properties / pull / enum
      Added value: +[
+  "always",
+  "missing",
+  "never"
+]
  2. First observedv1.9.0

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses important non-obvious behaviors: it always runs detached, does not raise on a non-zero CLI exit, raises only on missing plugin/timeout, and copies project_dir to the target host when no local plugin exists. These details go well beyond the sparse readOnly/destructive annotations and materially affect how an agent interprets results.

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 tightly organized: a one-line purpose, then behavioral caveats, a compact args list, and a return type. Each sentence earns its place, and the most important constraints are front-loaded. No fluff or repetition exists.

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?

The description covers invocation defaults, error semantics, return shape, and path handling, which is strong for a tool with no output schema. The only notable omission is the profiles parameter, so an agent would not know that profiles can be explicitly selected.

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 carries the parameter documentation burden and documents nine of the ten parameters with useful default and behavior notes, such as timeout_seconds default 600, wait adding --wait, and pull behavior. However, the profiles parameter present in the input schema is not mentioned at all, which is a real gap.

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 states a concrete verb-resource pair: 'Bring up a Docker Compose project, detached.' It immediately distinguishes this from compose_stop, compose_ps, and other compose operations with an unambiguous command intent. Even without the title, the tool's purpose is clear.

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?

It gives explicit guidance to use compose_ps to confirm services are running, or wait=True to block until healthy. This provides clear situational usage for the common follow-up decision. It does not explicitly compare against compose_start/compose_restart, but the detached-operation context is sufficient for an agent to know when this is appropriate.

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