Skip to main content
Glama
Krelborn

docker-compose-mcp

by Krelborn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Run Docker Compose Command

docker_compose_command

Run any Docker Compose command on a specific compose file to manage containers, view logs, restart services, or execute commands.

Instructions

Execute any docker compose command for a specific compose file.

This tool allows running arbitrary docker compose commands like:

  • ps: List containers

  • logs: View container logs

  • restart: Restart services

  • stop/start: Stop or start services

  • exec: Execute commands in running containers

Args:

  • compose_file (string): Absolute path to the docker-compose.yml file

  • command (string): Docker compose command to run (everything after 'docker compose -f file.yml')

Returns: The stdout and stderr output from the docker compose command

Examples:

  • Use when: "Show me the logs for my docker containers"

  • Use when: "List running docker compose services"

  • Use when: "Restart the web service"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesDocker compose command to run (e.g., 'ps', 'logs', 'restart')
compose_fileYesAbsolute path to the docker-compose.yml file

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With annotations already declaring readOnly=false, destructive=false, openWorld=false and idempotent=false, the description usefully adds that the command is arbitrary passthrough and that stdout/stderr are returned. It does not address permissions, side-effect risk, or that some listed commands (stop/start/restart/exec) mutate running state, which is worth flagging given destructiveHint=false.

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?

Front-loaded opening sentence states the operation immediately, and the bulleted subcommand list plus examples are scannable. The 'Args/Returns/Examples' scaffolding is slightly heavier than needed for a two-parameter tool, but nothing is wasted.

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?

No output schema exists, and the description compensates by explaining that stdout and stderr are returned. Inputs, return shape, and usage scenarios are all covered; the only meaningful gap is the absence of any note about interaction with the sibling update tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The Args section restates both parameters, and only the clarification that 'command' is everything after 'docker compose -f file.yml' genuinely adds meaning beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Execute any docker compose command for a specific compose file') and even enumerates supported subcommands, so the purpose is unmistakable. It stops short of distinguishing itself from the sibling docker_compose_update, leaving the agent to infer that mutation-by-update goes elsewhere.

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?

Three concrete 'Use when' examples anchor real scenarios (view logs, list services, restart a service), which is solid contextual guidance. However, there are no exclusions and no routing to docker_compose_update, so the agent gets positive signals but no disambiguation.

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