Skip to main content
Glama

compose_cp

Copy files or folders between a Docker Compose service container and the host filesystem. Specify source and destination as either SERVICE:PATH or a host path to transfer data in either direction.

Instructions

Copy files/folders between a service container and the server host's filesystem.

Exactly one of source/dest is SERVICE:PATH; the other is a path on the host running this MCP server, read/written as the server's user (same host exposure as the file-path archive tools - see SECURITY.md). Copying to stdout (dest="-") is unsupported; use container_archive_get. Does not raise on a non-zero CLI exit (a missing compose plugin or a timeout still raises) - inspect returncode/stderr in the result. With no local compose plugin and an ssh:// target, runs the real docker compose cp on that host instead and relays whichever side of the copy is local over the same SSH connection - every parameter above behaves the same either way, since the actual copy always runs through the real CLI. The one difference: a container->host copy is refused if the local destination already exists, since only this host (not the remote one) knows that. unix:///tcp://+TLS hosts with no local plugin are not covered by this fallback (no shell to run the CLI on) and still raise CapabilityError - use container_archive_put (host to container) or container_archive_get_to_file (container to host) there instead; both talk to the daemon directly and need no local CLI (compose_ps gives you the container name).

Args: source: SERVICE:SRC_PATH or a host path dest: SERVICE:DEST_PATH or a host path (not "-") index: Container index when the service has multiple replicas all_containers: Copy to/from all containers of the service (--all) project_dir: Dir with the compose file (default: server cwd; copied to the target host if no local plugin) files: Explicit compose file paths (repeatable, -f) project_name: Compose project name override timeout_seconds: Subprocess timeout (default 300s)

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
destYes
filesNo
indexNo
sourceYes
project_dirNo
project_nameNo
all_containersNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses non-obvious behavioral traits: it does not raise on a non-zero CLI exit but does raise on missing plugin/timeout, it refuses container->host copies when the local destination already exists, and it has a CapabilityError case for unix:///tcp://+TLS hosts. These details go far beyond what the annotations supply and fully characterize the tool's fault model.

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 long but each paragraph carries a distinct load: overview, stdout limitation, error semantics, SSH fallback, unix:///tcp:///cases, parameters, and return form. There is minor redundancy (the 'no local compose plugin' condition appears twice) and the density risks truncation in the UX, but the structure is logical and mostly 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?

Given the 8 parameters, no output schema, and no schema-described fields, the description is complete: it writes the return shape (returncode/stdout/stderr/truncated), the error taxonomy (non-zero exit, missing plugin, timeout, CapabilityError), the host-permission exposure, and the remote-host fallback semantics. An agent has everything needed to call it correctly without needing supplementary documentation.

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?

The schema has zero parameter descriptions (0% coverage), so the description completely compensates. Each of the eight parameters gets meaningful detail: source/dest format, index for replicas, all_containers semantics, project_dir default and remote-copy behavior, repeatable files, project_name override, and timeout_seconds default. This fully equips the agent to pass correct args without opening the 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 uses a specific verb and resource: "Copy files/folders between a service container and the server host's filesystem." It also explains the required source/dest format (SERVICE:PATH on exactly one side) and explicitly excludes copying to stdout, which distinguishes it from related tools like container_archive_get and container_archive_put.

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?

The description names when to use alternative tools: copying to stdout should use container_archive_get; unix:///tcp://+TLS hosts without a local plugin should use container_archive_put or container_archive_get_to_file. It also explains the SSH fallback behavior and when the tool is not covered, giving the agent clear decision rules for choosing this tool vs. alternatives.

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