用于 Docker 操作的模型上下文协议 (MCP) 服务器。该服务器允许 Claude 和其他 AI 助手通过 MCP 协议与 Docker 进行交互。
**注意：**此 MCP 服务器使用标准 Docker CLI 命令，目前不支持 Docker Compose 操作，其他带有 docker-compose 的 MCP 服务器尚无法可靠地与 cline 配合使用。
列出 Docker 容器
列出 Docker 镜像
运行 Docker 容器
停止运行容器
删除容器
从注册表中提取 Docker 镜像
Related MCP server: Docker MCP Server
Node.js 18 或更高版本
Docker 已安装并正在您的系统上运行
npm install -g docker-mcp-server克隆此存储库
安装依赖项：
cd docker-mcp
npm install构建项目：
npm run builddocker-mcp-server或者如果从源安装：
npm start您可以使用附带的安装脚本通过 Claude 自动配置 Docker MCP 服务器：
npm run install-config该脚本将：
检测您的 Claude 安装（桌面和/或 VSCode）
更新配置文件以包含 Docker MCP 服务器
为您的系统设置正确的路径
如果您希望手动配置，则需要将 Docker MCP 服务器添加到您的 MCP 设置配置文件中：
编辑~/Library/Application Support/Claude/claude_desktop_config.json ：
{
"mcpServers": {
"docker-mcp": {
"command": "node",
"args": ["/path/to/docker-mcp/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}编辑~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json ：
{
"mcpServers": {
"docker-mcp": {
"command": "node",
"args": ["/path/to/docker-mcp/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}**注意：**在 VS Code 中配置 Docker MCP 服务器后，可能需要重启 VS Code 才能使更改在 Cline 中生效。如果您在 Cline 中遇到 Docker MCP 服务器无法识别或无法正常工作的问题，请尝试重启 VS Code。
列出所有 Docker 容器。
参数：
all （布尔值，可选）：显示所有容器（默认显示正在运行的容器）
列出所有 Docker 镜像。
运行 Docker 容器。
参数：
image （字符串，必需）：要运行的 Docker 映像
name （字符串，可选）：容器的名称
detach （布尔值，可选）：在后台运行容器
ports （字符串数组，可选）：端口映射（例如 [“8080:80”]）
volumes （字符串数组，可选）：卷映射（例如 [“/host/path:/container/path”]）
env （字符串数组，可选）：环境变量（例如[“KEY=value”]）
command （字符串，可选）：在容器中运行的命令
停止正在运行的 Docker 容器。
参数：
container （字符串，必需）：容器 ID 或名称
删除 Docker 容器。
参数：
container （字符串，必需）：容器 ID 或名称
force （布尔值，可选）：强制删除正在运行的容器
从注册表中提取 Docker 镜像。
参数：
image （字符串，必需）：图像名称（例如“nginx：latest”）
配置完成后，您可以要求Claude执行Docker操作：
“运行一个 hello-world Docker 容器”
“列出所有 Docker 容器”
“拉取最新的 nginx 镜像”
“在端口 8080 上运行 nginx 容器”
“停止 nginx 容器”
“删除所有停止的容器”
该 Docker MCP 服务器可在 Cline MCP Marketplace 上获取，用户可以轻松发现并一键安装。
MCP 市场提交的徽标位于assets/logo.png文件中。
有关 MCP 市场的更多信息，请访问：
麻省理工学院
List all Docker containers
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Show all containers (default shows just running) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only says 'List'. It does not mention that running without 'all' excludes stopped containers, and the word 'all' actually conflicts with the schema's stated default of showing only running containers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. The main action and resource are front-loaded, and nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the schema covers the parameter, but the description alone is incomplete: it fails to clarify the running-only default and contains an 'all' wording that could mislead an agent. The missing usage context lowers completeness below what a strong minimal definition would provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'all' parameter is already clearly documented in the schema. The tool description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear action ('List') and resource ('Docker containers'), and it is easy to distinguish from sibling tools like list_images or list_volumes. However, the word 'all' is ambiguous because the schema says the default is just running containers, so the description slightly overstates the default behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other list tools, nor when to set the 'all' parameter. The schema's parameter description implies the default behavior, but the tool description itself offers no selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Docker images
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. 'List' clearly signals a read-only operation, but the description does not explicitly state that it has no side effects, what outputs it returns, or other behavioral details such as sorting or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and object. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool with no complex side effects, 'List all Docker images' is sufficient for an agent to select and invoke the tool correctly. There is no missing information that would prevent correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter documentation is unnecessary. The word 'all' reinforces that no filtering or arguments are expected, which is consistent with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('Docker images'), immediately distinguishing it from sibling tools like list_containers and list_volumes. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb-resource pairing: use this tool to enumerate Docker images. However, there is no explicit guidance about when not to use it or which alternative to prefer, though the simple scope makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull a Docker image from a registry
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Image name (e.g. "nginx:latest") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose that pulling downloads data, requires registry access, may need authentication, consumes disk space, or can be a long-running operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no filler. It front-loads the core purpose and is appropriately sized for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema is minimally viable for invoking the tool with one parameter, but it lacks behavioral context such as side effects, registry access requirements, and failure modes. It could be more complete despite the simple interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema adequately documents the image parameter with an example. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: pulling a Docker image from a registry. This clearly distinguishes it from sibling tools like build_image, run_container, and list_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as build_image or when pulling is needed before run_container. Usage context is only implied by the verb 'pull.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a Docker container
| Name | Required | Description | Default |
|---|---|---|---|
| container | Yes | Container ID or name | |
| force | No | Force removal of running container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Remove a Docker container' and fails to disclose that removal is destructive, that running containers require the force flag, or that the operation is irreversible. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified rather than appropriately concise. The brevity comes at the cost of omitting important behavioral and usage context for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a destructive action, the description is not complete enough. An agent cannot infer the delete semantics, the force behavior, or how this differs from stop_container. For such a simple tool, these missing details are critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'container' and 'force' already documented in the input schema. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Remove') and a specific resource ('Docker container'), which distinguishes it from sibling tools like remove_network and stop_container. However, it closely paraphrases the tool name and does not clarify that 'remove' means delete rather than stop, so it stops short of a fully informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like stop_container, nor any mention of prerequisites such as the container needing to exist or not be running unless force is used. The usage context is only implied by the verb 'remove'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Docker container
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Docker image to run | |
| name | No | Name for the container | |
| detach | No | Run container in background | |
| ports | No | Port mappings (e.g. ["8080:80"]) | |
| volumes | No | Volume mappings (e.g. ["/host/path:/container/path"]) | |
| env | No | Environment variables (e.g. ["KEY=value"]) | |
| command | No | Command to run in the container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. 'Run a Docker container' implies creating and starting a container but does not mention image pulling behavior, container lifecycle side effects, detach semantics, or what the tool returns after running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. However, it is so minimal that it misses opportunities to add useful behavioral or usage context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should compensate by explaining return values and side effects, but it does not. An agent is left without key information about what happens after invoking run_container, such as whether a container ID is returned or whether the image is pulled automatically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all seven parameters with 100% coverage, so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run') on a specific resource ('a Docker container'). It is distinguishable from sibling tools like stop_container, remove_container, and exec_container by its core operation, though it does not explicitly contrast itself with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as compose_up for multi-container workflows or exec_container for running commands in an existing container. The description simply states what the tool does without any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running Docker container
| Name | Required | Description | Default |
|---|---|---|---|
| container | Yes | Container ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the primary action but does not explain side effects such as the container remaining present but stopped, needing to be running first, or that this is non-destructive. No contradictions exist, but depth is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words and directly front-loads the action and target. It is appropriately sized for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description covers the basic purpose but misses behavioral context such as state change, non-destructiveness, and how it differs from removal. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented as 'Container ID or name'. The description adds little beyond the schema, but the schema is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Stop') and resource ('a running Docker container'), so an agent immediately knows the core operation. It does not explicitly distinguish itself from siblings like remove_container, but 'stop' versus 'remove' is reasonably clear from the action word.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description does not mention that this only applies to running containers, that it should not be used to remove a container, or when run_container or remove_container would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_containerslist_imagespull_imageremove_containerrun_containerstop_containerScored across 6 tools
Each tool has a clearly distinct purpose targeting specific Docker resources and actions. For example, list_containers vs. remove_container vs. run_container have no overlap, making it easy for an agent to select the right tool without confusion.
All tools follow a consistent verb_noun pattern with snake_case (e.g., list_containers, pull_image, stop_container). There are no deviations in naming conventions, making the set predictable and readable.
With 6 tools, this is well-scoped for basic Docker operations. Each tool earns its place by covering essential container and image management tasks without being overly sparse or bloated.
The toolset covers core Docker workflows like listing, running, stopping, and removing containers, plus image listing and pulling. A minor gap exists in image management (e.g., no remove_image or inspect tools), but agents can work around this for most common tasks.
Hosting for AI agents: your AI client deploys Docker apps to live HTTPS URLs over MCP.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
