Docker MCP Server vs Chatpack MCP
A side-by-side look at the Docker MCP Server and Chatpack MCP 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 Chatpack MCP for developer tools as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Docker MCP Server when
- You need dedicated capabilities in the Developer Tools domain.
- You prefer a local stdio subprocess transport.
- You want tools like
docker_container, docker_container_control, docker_compose.
Choose Chatpack MCP when
- You need dedicated capabilities in the Developer Tools domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
search_docs, get_document, get_integration_guide.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Developer Tools | Developer Tools |
| Quality signal | 59/100 · Good | 87/100 · Excellent |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Verified |
| GitHub stars | 0 | 224 |
| Directory activity | 2 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 10 | 5 |
| Full listing | View Docker MCP Server | View Chatpack MCP |
Tools & capabilities
Docker MCP Server tools 10
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.
Chatpack MCP tools 5
search_docsSearch bundled Chatpack documentation and the authoritative llms reference. Returns document ids, links and matching excerpts with package versions.get_documentRead a complete bundled Chatpack document by id. Use llms for the authoritative integration contract or concepts/errors for troubleshooting.get_integration_guideRetrieve the repository's framework setup guide with authentication guidance and the authoritative llms reference. Examples match the bundled package versions.list_ui_blocksList public runtime exports of @chatpack/ui, including components, providers and utilities. Returns names accepted by get_ui_block.get_ui_blockRetrieve a public @chatpack/ui export's source module and usage guide. Optionally include supporting UI modules and stylesheet. Files are reference source, not a standalone copy-and-paste component.
Ready-to-paste client configs
Paste 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.
Docker MCP Server
{
"mcpServers": {
"docker-mcp-server": {
"command": "npx",
"args": [
"-y",
"@hypnosis/docker-mcp-server"
]
}
}
}
Chatpack MCP
{
"mcpServers": {
"chatpack-mcp": {
"command": "npx",
"args": [
"-y",
"@chatpack/mcp"
]
}
}
}
Frequently asked questions
Docker MCP Server is categorized under Developer Tools and uses a local stdio subprocess. Chatpack MCP belongs to Developer Tools and uses a local stdio subprocess. Pick Docker MCP Server for developer tools work and Chatpack MCP for developer tools.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Docker MCP Server has no declared pricing — check the project's own site. Chatpack MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add docker-mcp-server and chatpack-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Docker MCP Server has a quality signal of 59/100 (Good) with 2 views, 0 installs and 0 GitHub stars. Chatpack MCP has 87/100 (Excellent) with 4 views, 0 installs and 224 GitHub stars.