## 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: ```yaml 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: ```json { "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: 1. Adds `--transport http` mode using FastMCP's built-in HTTP support (`run_streamable_http_async`) 2. Adds a `Dockerfile` that installs the package, exposes port 8080, mounts `/var/run/docker.sock` as a volume, and defaults to HTTP transport 3. 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.