GitHub
GitHub’s official server lets AI read and manage code, issues and pull requests in your account. Use GitHub’s hosted version or run it locally with Docker.
Description from the maker (original English)
Docker for AI agents — containers, compose stacks, logs and databases, locally or over SSH.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
DOCKER_MCP_PROFILES_FILE, DOCKER_PROFILES, DOCKER_MCP_ALLOW_SSH_FALLBACK, LOG_LEVELYou need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"docker": {
"command": "npx",
"args": [
"-y",
"@hypnosis/docker-mcp-server"
],
"env": {
"DOCKER_MCP_PROFILES_FILE": "your-value",
"DOCKER_PROFILES": "your-value",
"DOCKER_MCP_ALLOW_SSH_FALLBACK": "your-value",
"LOG_LEVEL": "your-value"
}
}
}
}Run this in your terminal
claude mcp add docker --env DOCKER_MCP_PROFILES_FILE=your-value --env DOCKER_PROFILES=your-value --env DOCKER_MCP_ALLOW_SSH_FALLBACK=your-value --env LOG_LEVEL=your-value -- npx -y @hypnosis/docker-mcp-serverFill in the empty values before running it.
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"docker": {
"command": "npx",
"args": [
"-y",
"@hypnosis/docker-mcp-server"
],
"env": {
"DOCKER_MCP_PROFILES_FILE": "your-value",
"DOCKER_PROFILES": "your-value",
"DOCKER_MCP_ALLOW_SSH_FALLBACK": "your-value",
"LOG_LEVEL": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"docker": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@hypnosis/docker-mcp-server"
],
"env": {
"DOCKER_MCP_PROFILES_FILE": "your-value",
"DOCKER_PROFILES": "your-value",
"DOCKER_MCP_ALLOW_SSH_FALLBACK": "your-value",
"LOG_LEVEL": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
DOCKER_MCP_PROFILES_FILE envDOCKER_PROFILES envDOCKER_MCP_ALLOW_SSH_FALLBACK envLOG_LEVEL envThese settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 7, 2026
The registry name was verified with the GitHub account hypnosis, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (2.0.1) reached the registry 2 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
In the same category: GitHub, Desktop Commander, Cloudflare MCP
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
GitHub’s official server lets AI read and manage code, issues and pull requests in your account. Use GitHub’s hosted version or run it locally with Docker.
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
A Docker MCP server that lets AI agents operate Compose stacks with structured, Docker-native tools — instead of brittle shell commands and terminal-shaped output.
Inspect containers, read logs, check health, query databases, take dumps, and bring stacks up or down — on your laptop or on a server across the world by naming its profile.
It speaks Docker the way you do: your compose files, project names, and service names. Answers come back as named fields with enough context for an agent to act on them, rather than parse an ASCII table and guess.
Works with Claude Code, Codex CLI, Cursor, opencode, Gemini CLI, Qwen Code and other MCP clients.
[Install](#install-in-30-seconds) · [Tools](#docker-mcp-tools-for-containers-compose-and-databases) · [Setup](#set-up-the-docker-mcp-server) · [Security](#destructive-command-protection-for-ai-agents) · [Docs](docs/tools.md) · [Changelog](CHANGELOG.md)
No global installation required. npx downloads the package on first use:
npx -y @hypnosis/docker-mcp-server
Add it to your MCP client — Claude Code, for example — for every project:
claude mcp add docker -s user -- npx -y @hypnosis/docker-mcp-server
That is the whole setup for the Docker on this machine. No profiles file, no environment variables: the server uses the local Docker socket, and the compose project of your working directory is the project it answers about.
For a Docker host on another machine, add one file with the servers you reach over SSH:
claude mcp add docker -s user \
-e DOCKER_MCP_PROFILES_FILE="$HOME/.claude/docker-profiles.json" \ -- npx -y @hypnosis/docker-mcp-server
{
"default": "local", "profiles": { "local": { "mode": "local" }, "production": { "host": "prod.example.com", "username": "deployer", "privateKeyPath": "~/.ssh/id_ed25519" } } }
Now every tool takes a profile, and docker_health({ action: "profiles" }) lists what the server was given.
Codex, Cursor, opencode and other clients are covered in Set up the Docker MCP server.
Some clients — Claude Code, for example — can take the whole thing as a plugin instead:
/plugin marketplace add hypnosis/docker-mcp-server
/plugin install docker-mcp-server@docker-mcp-server
The plugin brings the server up against the Docker on this machine, with no configuration at all. Point it at other hosts the same way as above, with DOCKER_MCP_PROFILES_FILE.
Node.js 18+ and a Docker daemon you can already reach — the local socket, or a remote host over SSH with a key.
The server starts whether or not Docker is up. A call made while the daemon is down answers "start Docker" and works on the next try, without restarting your MCP client.
Prefer a pinned version, offline work, or one less registry check per launch: npm install -g @hypnosis/docker-mcp-server, then use docker-mcp-server as the command instead of npx.
Docker CLI is excellent for a person at a terminal. An AI agent needs something different: Docker and Compose concepts it can query directly, results it can reason about, and clear boundaries between what happened, what was not found, and what could not be checked.
docker ps, docker stats, and docker logs are designed to be read on a screen. Their output mixes labels, values, units, and formatting into text an agent must parse before it can use it.
A Docker MCP tool returns the fields the task needs: service, project, state, health, ports, timestamps, byte counts, exit codes, and log streams. The agent receives less terminal noise, spends fewer tokens interpreting it, and keeps more context for the problem it is solving.
A Docker application is more than a list of containers. It is a Compose project with services, dependencies, health checks, logs, databases, and resources that affect one another.
The server lets an agent ask about that system in the names you use every day: the project, service, and Compose file. One call can show the state and health of a stack; another can inspect a bounded log window, measure a service, or query the database already running beside it. The agent spends its turns finding the cause, not assembling and decoding shell commands.
A shell command can return an empty table, clipped output, or an error printed alongside ordinary text. For an agent, those are different situations — and treating them as the same leads to guesses.
Docker MCP results say what was found, what was not found, what was cut short, and why an action did not run. A missing healthcheck is not a failed healthcheck; an empty list is not a failed read; a command with no exit code never started. That gives the agent a reliable basis for its next step, and gives you fewer confident-looking but wrong fixes.
Use the same Docker MCP tools on the Docker daemon beside you and on a remote server. A remote Docker host is a profile: a stable name, its SSH connection, and the authentication it needs. The agent names that profile in a tool call:
docker_container({ "action": "list", "profile": "production" })
Leave profile out and the default Docker host answers, so local development stays frictionless. Name a profile the server does not know and the response lists the profiles it does know instead of quietly sending a request to another machine.
Remote Docker Compose projects are resolved by the labels their containers already carry. Ask for a project by name wherever it lives on that host — no remote working directory or fixed Compose path to maintain. For a project that has not run there yet, pass its file explicitly with compose_path.
A native Docker MCP server built on the official MCP SDK, with structured tools designed for AI agents rather than terminal automation.
Its behaviour is covered by unit tests and end-to-end tests that run against real Docker containers, not only mocks.
The Docker CLI is the right interface when a person is driving the terminal. These examples show what changes when an AI agent needs to inspect a Docker Compose application, understand the result, and choose the next safe step.
Each comparison uses the same real-world task: first the commands and output an agent would have to work through, then the structured Docker MCP result it can use directly.
Situation: A deploy just went out. The site is slow, and you do not know whether a
container is down, a healthcheck is failing, or something is eating the memory.
Question: "Is this stack healthy?"
$ docker compose ps
NAME IMAGE STATUS PORTS shop-api-1 shop-api:latest Up 4 minutes (healthy) 0.0.0.0:8080->8080/tcp shop-postgres-1 postgres:16 Up 4 minutes (unhealthy) 5432/tcp shop-worker-1 shop-worker:latest Exited (1) 2 minutes ago $ docker stats --no-stream CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O 1f2c4d5e6a7b shop-api-1 3.10% 214.8MiB / 7.66GiB 2.74% 12.4MB / 8.9MB 0B / 4.1MB 9a8b7c6d5e4f shop-postgres-1 0.42% 1.204GiB / 7.66GiB 15.7% 3.2MB / 44MB 112MB / 890MB $ docker inspect --format '{{.State.Health.Status}}' shop-postgres-1 unhealthy $ docker inspect --format '{{.State.Health.Status}}' shop-worker-1 Template parsing error: executing "" at <.State.Health.Status>: nil pointer evaluating *types.Health.Status
Three commands, three formats, and the last one fails because the worker image declares no healthcheck at all. Nothing is broken — there is simply nothing to read — but the agent now has to tell "no healthcheck" apart from "failing", and a table gives it no help.
docker_container({ "action": "list", "project": "shop" })
{
"action": "list", "project": "shop", "containers": [ { "name": "shop-api-1", "service": "api", "project": "shop", "state": "running", "health": "healthy", "image": "shop-api:latest", "ports": ["0.0.0.0:8080->8080/tcp"], "created": "2026-08-24T09:14:02Z" }, { "name": "shop-postgres-1", "service": "postgres", "project": "shop", "state": "running", "health": "unhealthy", "image": "postgres:16", "ports": ["5432/tcp"], "created": "2026-08-24T09:14:01Z" }, { "name": "shop-worker-1", "service": "worker", "project": "shop", "state": "exited", "health": null, "image": "shop-worker:latest", "ports": [], "created": "2026-08-24T09:14:01Z" } ], "reason": null, "legend": { "containers[].state=running": "Running now.", "containers[]
Only the beginning is shown; read the rest in the repo