mcp-server-docker
MCPA Docker MCP Server
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ✓ | Complex nested types in CreateContainerInput (ports, volumes) may require flattening for optimal OpenAI compatibility |
| LangChain | ✓ | Docker SDK state (client connection) needs careful handling in LangChain's execution model |
Security findings
Direct Docker socket access allows arbitrary container creation with host filesystem access
The server accepts volume mounts in CreateContainerInput without validation (volumes: dict[str, dict[str, str]] | list[str] | None). An attacker can mount the host root filesystem (e.g., '/:/host') and execute commands to compromise the host system. The README explicitly shows mounting /var/run/docker.sock.
Command injection via container entrypoint and command parameters
CreateContainerInput accepts arbitrary 'entrypoint' and 'command' strings without validation or sanitization. These are passed directly to docker.containers.create(), allowing execution of arbitrary commands in containers with mounted host volumes.
Arbitrary Docker image execution from untrusted sources
The 'pull_image' and 'create_container' tools accept any image name without validation. An attacker can pull and execute malicious images from public registries. Combined with volume mounting, this enables full host compromise.
No authorization or authentication model
The server has no authentication, authorization, or permission checks. Any caller with MCP access can perform all Docker operations including container deletion, image removal, and network manipulation.
Unrestricted network creation and attachment
The 'create_network' tool and CreateContainerInput.network field allow arbitrary network configuration without validation. This could enable network pivoting attacks or bypass of network security controls.
SSH connection string injection risk
The DOCKER_HOST environment variable accepts ssh:// URLs with user-supplied credentials in the connection string. While the Python Docker SDK handles parsing, there's potential for SSH command injection if special characters aren't properly escaped.
Verbose error messages may leak system information
No input length limits on string fields
JSON parsing vulnerability in field validator
Reliability
Success rate
78%
Calls made
100
Avg latency
450ms
P95 latency
1200ms
Failure modes
- • Docker daemon connection failures return unstructured exceptions from docker-py SDK
- • Missing container/image/network/volume returns docker.errors.NotFound which may not be caught consistently
- • JSON parsing in JSONParsingModel validator fails silently on malformed input, returning the string unparsed
- • No timeout handling on Docker operations - long-running operations (pull_image, build_image) can hang indefinitely
- • Container creation with invalid port mappings or volume mounts will raise docker.errors.APIError without structured error handling
- • Race conditions possible when recreating containers - stop+remove+create sequence not atomic
- • No validation of Docker image names before pull/run operations
- • Empty or null container_id parameters pass pydantic validation but fail at Docker SDK level
- • Unicode in container names or labels may cause encoding issues depending on Docker version
- • Concurrent container operations not synchronized - could lead to state inconsistencies
Code health
License
GPL-3.0
Has tests
No
Has CI
No
Dependencies
5
Active project with good documentation and type hints. Uses modern Python tooling (uv, Pydantic v2). Has clear license (GPL-3.0). Published to PyPI. Main gaps: no tests, no CI/CD, no changelog. Code quality is good with linter config (ruff via devbox). Well-structured with input/output schemas. Missing test suite is the biggest concern for a tool that manages Docker containers. Repository metadata (commit history, issues) not available for analysis.