A side-by-side look at the Docker MCP Server and Komodo MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Docker MCP Server for developer tools work as a local process; choose Komodo MCP Server for developer tools as a local process. You can also run both side by side in one mcpServers block.
docker_container, docker_container_control, docker_compose.KOMODO_URL, KOMODO_API_KEY, KOMODO_API_SECRET.komodo_list_servers, komodo_get_server, komodo_get_server_stats.Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Developer Tools | Developer Tools |
| Quality signal | 59/100 · Good | 55/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | KOMODO_URLKOMODO_API_KEYKOMODO_API_SECRET |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 7 |
| Directory activity | 2 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 10 | 63 |
| Full listing | View Docker MCP Server | View Komodo MCP Server |
docker_containerLists the containers of a project with their state, health and published ports, or measures with stats what one service consumes right now. A project name no container carries is refused with the names that exist, so an empty list means the host itself runs nothing under compose. Moving a container between states is docker_container_control.docker_container_controlMoves one service between states — start, stop, restart — and reports where it stood before and where it stands now, with changed saying whether the call did anything at all. A stop that ran out of time comes back killed with its exit code, never as a clean stop. The whole stack at once is docker_compose_control.docker_composeReads what the project declares: config for the resolved compose file, env for the variables with the file each came from. Both read files rather than a running process — a variable here is what was written down, not what the container now holds. What is actually running is docker_container.docker_compose_controlBrings the stack up or takes it down, and reports the containers standing afterwards as read from the daemon, not as compose described them. A stack that half came up says so instead of passing for a success. Taking volumes down with it destroys their data and is refused without confirm.docker_execRuns a command inside a service container and brings back its exit code, with stdout and stderr apart. exit_code null means the command never ran and reason says why; an empty stdout means it ran and said nothing. What destroys data is refused until the command carries # CONFIRMED-DESTRUCTIVE. Reading logs, asking a database and taking dumps have tools of their own.docker_logsReads what a container printed, line by line: each line carries the stream that wrote it and its own time. An empty list means the window held nothing, not that the read failed, and lines dropped from the middle are counted rather than quietly lost. Narrow the window with since and until instead of raising the count.docker_dbquery runs a statement against a database container, status asks the database about itself — version, size, uptime. PostgreSQL, MySQL/MariaDB, Redis, MongoDB and SQLite are spoken to through the client the image carries. A database that refuses answers with its exit code, not with a failed call. A statement that destroys data needs # CONFIRMED-DESTRUCTIVE.docker_db_adminbackup takes a dump of a database container, restore fills the database from one. The answer names the file, its size and whether it was read back: a call that says done without naming a file of known size says nothing. Restore overwrites what is there and is refused without confirm — take a backup here first.docker_healthservices says whether the containers answer their healthchecks, server whether this process is well, profiles which Docker hosts it was given. The word healthy means something different in each branch, so every answer explains its own verdict. A service that declares no healthcheck is said to have none, not counted as sick.docker_resourceimages, volumes and networks list what a host holds; disk counts what they take, with unused bytes apart from the total. An empty list means asked and found nothing, which is not the same as never asked. What a running container consumes right now is docker_container with stats.komodo_list_serversList all servers with status and regionkomodo_get_serverGet server configuration, status, and action statekomodo_get_server_statsGet CPU, memory, disk usage, and load averageskomodo_get_server_infoGet OS details, hardware info, and running processeskomodo_inspect_docker_containerInspect a Docker container (`docker inspect` payload); env values render as `sha256:<12-hex>` digests unless `show_env_values: true` (refused on the `read-only` tier unless `KOMODO_ALLOW_ENV_VALUES=true`) -- redaction covers `Env` arrays only, so labels, cmd, and mounts are returned unredactedkomodo_inspect_docker_imageInspect a Docker image (`docker image inspect` payload); baked-in env values render as `sha256:<12-hex>` digests unless `show_env_values: true` (refused on the `read-only` tier unless `KOMODO_ALLOW_ENV_VALUES=true`) -- redaction covers `Env` arrays only, so labels, cmd, and layers are returned unre…komodo_inspect_docker_networkInspect a Docker network (equivalent to docker network inspect)komodo_inspect_docker_volumeInspect a Docker volume (equivalent to docker volume inspect)komodo_prune_dockerPrune unused Docker resources on a serverkomodo_delete_docker_resourceDelete a specific Docker image, volume, or networkkomodo_list_stacksList all stacks with state, server, and service countkomodo_get_stackGet stack configuration, services, and action statePaste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
{
"mcpServers": {
"docker-mcp-server": {
"command": "npx",
"args": [
"-y",
"@hypnosis/docker-mcp-server"
]
}
}
}
{
"mcpServers": {
"komodo-mcp-server-2": {
"command": "npx",
"args": [
"-y",
"@samik081/mcp-komodo"
],
"env": {
"KOMODO_URL": "YOUR_KOMODO_URL_HERE",
"KOMODO_API_KEY": "YOUR_KOMODO_API_KEY_HERE",
"KOMODO_API_SECRET": "YOUR_KOMODO_API_SECRET_HERE"
}
}
}
}