MCP Server for Docker: Options & Config

"MCP server for Docker" means one of two things, and the config is different for each. Either you want to run an MCP server as a Docker container — pinned image, no npx on your PATH — or you want to give the agent control over Docker itself: list containers, read logs, run images. This piece covers both, names the servers worth using, and gives you a config you can paste.

First, a fact that shapes everything below: about 90% of MCP servers run locally over stdio. Docker doesn't change that. A containerized server still speaks stdio to your client — the client just runs docker run instead of npx. Same protocol, different launcher.

Running an MCP server as a Docker container

Use Docker as the launcher when you want a pinned, reproducible server that doesn't depend on Node or Python being installed on the host. The client runs docker run with -i (interactive stdin) so the container can speak stdio, and you swap the ephemeral flags in.

The cleanest example is GitHub MCP Server, GitHub's official server. It ships as a container image, so the config is just docker run plus your token:

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
    }
  }
}

Two flags matter here. -i keeps stdin open — drop it and the server can't receive messages. --rm deletes the container on exit so you're not leaking stopped containers every restart. That's the whole trick; the JSON shape is identical to any other stdio server, only the command changed.

Servers that already ship as Docker images

A handful of the better-maintained servers are distributed as images first, npx second — which is a decent maintenance signal on its own. These are worth reaching for when you want reproducibility over convenience.

Server	What it does	Runs in Docker
GitHub MCP Server	Repos, issues, PRs, Actions; official	Yes — official image
OpenMemory MCP	Local-first agent memory + dashboard	Yes — Docker is the primary install
Grafana MCP Server	Dashboards, Prometheus/Loki queries, alerts	Yes — official image
Terraform MCP Server	Registry providers, modules, IaC lookups	Yes — official image
Postgres MCP Pro	Read/write Postgres, EXPLAIN, index tuning	Yes — image or uvx

OpenMemory MCP is the interesting one: it's Mem0's memory layer, and Docker isn't an alternative install — it's the intended one, because the server ships alongside a dashboard and a vector store that are painful to wire up by hand. When a project's docs lead with docker compose up, take the hint.

Giving an agent control over Docker itself

This is the other reading of the query, and it's the one to be careful with. A Docker-control MCP server exposes tools like list_containers, get_logs, run_container, and exec. Read-only introspection (list, inspect, logs) is genuinely useful for debugging — "why did this container crash" is a great agent task.

The write side is where I'd stop and think. A tool that runs docker run or exec on the model's say-so is, effectively, arbitrary code execution: the container can mount host paths, hit your network, and the agent can be steered there by anything it reads. If you use one, prefer a server that separates read tools from write tools, and don't hand it a socket with more reach than the task needs.

Most Docker-control servers today are community builds rather than an official Docker product, so vet the repo the way you'd vet any community vs. official server: is it maintained, is it read-only by default, what does it actually expose.

Docker as launcher vs. Docker as target

The distinction is worth making explicit because it changes what you're risking.

	Docker as launcher	Docker as target
What runs in a container	The MCP server	The workloads the agent manages
Config command	docker run ... <image>	npx/docker for the control server
Main benefit	Reproducible, no host runtime	Agent can inspect/operate containers
Main risk	Almost none — same as any stdio server	Write tools = code execution surface
Skip it when	You already have Node/uv and want speed	You only need read-only introspection

Running a server in Docker is close to free risk. Letting an agent operate Docker is a real decision. Don't let the shared keyword blur them.

Watch the tool budget either way

Whichever path you take, containerizing a server doesn't shrink its tool list. Every server you add dumps its tools into the client's active set, and selection quality degrades past ~40 active tools — the average server is ~12 tools, so four servers is the realistic ceiling, not forty.

Docker changes the launcher, not the arithmetic. If you're stacking GitHub, a Docker-control server, and Postgres MCP Pro in one project, you're already near the line. Scope servers per-project and browse by capability rather than installing everything that looks handy.

Start from the best MCP servers if you want the maintained shortlist, or the alternatives view when a server exists but isn't the one you want to run.