Summary
This project already does the hard part — Docker SDK integration via the Unix socket. The missing piece is an HTTP transport mode so it can be deployed as a standalone container accessible at http://localhost:<port>/mcp rather than requiring a stdio subprocess on the host.
Use case
Many agent orchestration setups (multi-agent systems, Claude Code MCP configs, etc.) prefer HTTP MCP servers they can declare once in a config file and share across sessions, rather than relying on claude_desktop_config.json subprocess launchers.
A containerised deployment pattern:
services:
docker-mcp:
image: docker-mcp:latest
ports:
- "127.0.0.1:4001:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
DOCKER_MCP_TRANSPORT: http
DOCKER_MCP_PORT: 8080
With a corresponding MCP client config:
{ "docker-mcp": { "type": "http", "url": "http://localhost:4001/mcp" } }
This is especially useful for homelab / self-hosted setups where multiple agents share a common pool of MCP services, all declared in a single config rather than per-client subprocess entries.
Proposed change
I'd like to contribute a PR that:
- Adds
--transport http mode using FastMCP's built-in HTTP support (run_streamable_http_async)
- Adds a
Dockerfile that installs the package, exposes port 8080, mounts /var/run/docker.sock as a volume, and defaults to HTTP transport
- Adds a
docker-compose.example.yml in docs/
The change would be backward-compatible — stdio remains the default, HTTP is opt-in via env var or CLI flag.
Questions for maintainer
- Is HTTP transport in scope for this project?
- Any preference on FastMCP vs raw
mcp server primitives for the transport layer?
- Would you accept a PR that adds this as an optional mode (stdio remains default)?
Happy to open a draft PR once there's alignment on direction.
Summary
This project already does the hard part — Docker SDK integration via the Unix socket. The missing piece is an HTTP transport mode so it can be deployed as a standalone container accessible at
http://localhost:<port>/mcprather than requiring a stdio subprocess on the host.Use case
Many agent orchestration setups (multi-agent systems, Claude Code MCP configs, etc.) prefer HTTP MCP servers they can declare once in a config file and share across sessions, rather than relying on
claude_desktop_config.jsonsubprocess launchers.A containerised deployment pattern:
With a corresponding MCP client config:
{ "docker-mcp": { "type": "http", "url": "http://localhost:4001/mcp" } }This is especially useful for homelab / self-hosted setups where multiple agents share a common pool of MCP services, all declared in a single config rather than per-client subprocess entries.
Proposed change
I'd like to contribute a PR that:
--transport httpmode using FastMCP's built-in HTTP support (run_streamable_http_async)Dockerfilethat installs the package, exposes port 8080, mounts/var/run/docker.sockas a volume, and defaults to HTTP transportdocker-compose.example.ymlin docs/The change would be backward-compatible — stdio remains the default, HTTP is opt-in via env var or CLI flag.
Questions for maintainer
mcpserver primitives for the transport layer?Happy to open a draft PR once there's alignment on direction.