Skip to main content
Glama

container_ops

Manage Docker container lifecycles: list, inspect, create, start, stop, restart, remove, execute commands, and retrieve logs or stats.

Instructions

Docker Container Lifecycle operations.

Operations: list_containers, get_container, create_container, start_container, stop_container, restart_container, remove_container, container_exec, container_logs, container_stats.

Args: See Parameters block.

Return Format

{"success": bool, "action": str, "message": str, "result": {...}}

  • list_containers: {"containers": [{"id", "name", "image", "status", ...}]}

  • container_logs: {"logs": str}

  • container_stats: {"stats": {...}}

Examples

container_ops(operation="list_containers", show_stats=True) container_ops(operation="container_logs", container_id="my-app", tail=50) container_ops(operation="restart_container", container_id="db", timeout=10)

Input Schema

NameRequiredDescriptionDefault
ttyNo
nameNo
tailNo
userNo
forceNo
imageNo
portsNo
sinceNo
stdinNo
untilNo
detachNo
followNo
socketNo
stderrNo
stdoutNo
streamNo
commandNo
timeoutNo
volumesNo
operationNo
show_statsNo
timestampsNo
auto_removeNo
environmentNo
working_dirNo
container_idNo
network_modeNo
restart_policyNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.1.0

TDQS

C2.7/5.0
Behavior1/5

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

The annotations declare destructiveHint=false, yet the description explicitly lists remove_container and stop_container, which are destructive lifecycle operations. The description also does not disclose irreversible deletion, force semantics, permission requirements, or the danger of calling remove_container.

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 the operation list, then return format and examples, so it is easy to scan. The line 'Args: See Parameters block' is wasted space, but the overall structure is efficient and not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-operation, 28-parameter tool, the description omits critical operation-specific parameter requirements and destructive behavior details. It does provide the operation list and return format, and an output schema exists, but that is not enough to guide correct invocation of a complex multi-operation tool.

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

Parameters2/5

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

There are 28 parameters with 0% schema description coverage, and the description mostly defers with 'Args: See Parameters block.' The examples mention only a few parameters (show_stats, container_id, tail, timeout) and do not explain operation-specific applicability for the remaining parameters.

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?

The description states the resource and scope clearly: 'Docker Container Lifecycle operations,' followed by an explicit operation list. It does not, however, distinguish this tool from overlapping siblings such as compose_up or host_ops, so sibling differentiation is incomplete.

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

Usage Guidelines3/5

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

The operation list and examples imply when individual operations are useful, such as checking logs or restarting a container. But there is no explicit guidance on when to use this tool versus compose_up, compose_down, or other siblings, and no exclusions or prerequisites are stated.

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