en es ja ko zh

docker-mcp

Name: docker-mcp
Author: QuantGeekDev

by QuantGeekDev

Overview Schema Source Related Servers Discussions Admin

Python

Local

🐳docker-mcp

Python 3.12 许可证：MIT 代码样式：黑色铁匠徽章

用于 Docker 操作的强大的模型上下文协议 (MCP) 服务器，通过 Claude AI 实现无缝容器和组合堆栈管理。

✨ 特点

🚀 容器创建和实例化
📦 Docker Compose 堆栈部署
🔍 容器日志检索
📊 集装箱清单和状态监控

🎬 演示

部署 Docker Compose 堆栈

https://github.com/user-attachments/assets/b5f6e40a-542b-4a39-ba12-7fdf803ee278

分析容器日志

https://github.com/user-attachments/assets/da386eea-2fab-4835-82ae-896de955d934

Related MCP server: MCP Development Server

🚀 快速入门

要在 Claude 桌面应用中尝试此功能，请将其添加到您的 claude 配置文件中：

{
  "mcpServers": {
    "docker-mcp": {
      "command": "uvx",
      "args": [
        "docker-mcp"
      ]
    }
  }
}

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 Docker MCP：

npx @smithery/cli install docker-mcp --client claude

先决条件

UV（包管理器）
Python 3.12+
Docker 桌面或 Docker 引擎
克劳德桌面

安装

Claude桌面配置

将服务器配置添加到您的 Claude Desktop 配置文件：

MacOS ： ~/Library/Application\ Support/Claude/claude_desktop_config.json
Windows ： %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "docker-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "<path-to-docker-mcp>",
        "run",
        "docker-mcp"
      ]
    }
  }
}

{
  "mcpServers": {
    "docker-mcp": {
      "command": "uvx",
      "args": [
        "docker-mcp"
      ]
    }
  }
}

🛠️ 开发

本地设置

克隆存储库：

git clone https://github.com/QuantGeekDev/docker-mcp.git
cd docker-mcp

创建并激活虚拟环境：

python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

安装依赖项：

uv sync

🔍 调试

启动 MCP Inspector 进行调试：

npx @modelcontextprotocol/inspector uv --directory <path-to-docker-mcp> run docker-mcp

Inspector 将提供一个 URL 来访问调试界面。

📝 可用工具

该服务器提供以下工具：

创建容器

创建独立的 Docker 容器

{
    "image": "image-name",
    "name": "container-name",
    "ports": {"80": "80"},
    "environment": {"ENV_VAR": "value"}
}

部署-撰写

部署 Docker Compose 堆栈

{
    "project_name": "example-stack",
    "compose_yaml": "version: '3.8'\nservices:\n  service1:\n    image: image1:latest\n    ports:\n      - '8080:80'"
}

获取日志

从特定容器中检索日志

{
    "container_name": "my-container"
}

列表容器

列出所有 Docker 容器

{}

🚧 当前限制

容器不支持内置环境变量
无音量管理
无网络管理
没有容器健康检查
没有容器重启策略
无容器资源限制

🤝 贡献

从docker-mcp fork 仓库
创建你的功能分支
提交你的更改
推送到分支
打开拉取请求

📜 许可证

该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。

✨ 作者

Alex Andru -初始工作 | 核心贡献者- @QuantGeekDev
Ali Sadykov -初始工作 | 核心贡献者- @md-archive

用❤️制作

Available Tools

4 tools

create-containerC

Create a new standalone Docker container

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`name`	No
`ports`	No
`environment`	No

TDQS

C2.8/5.0

Behavior2/5

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 'Create' implying a mutation operation but doesn't cover permissions, side effects, error handling, or response format. For a tool that likely requires Docker daemon access and creates persistent resources, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a basic tool definition and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't address parameter meanings, behavioral traits, or output expectations, leaving the agent with insufficient context to use the tool effectively beyond the basic purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'image', 'name', 'ports', or 'environment' mean in the Docker context, their formats, or examples. With 4 parameters and nested objects, this leaves critical usage details undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and resource ('new standalone Docker container'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'deploy-compose' which might also create containers, missing the 'standalone' distinction that could be more explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'deploy-compose' for multi-container setups or 'list-containers' for viewing existing ones. The description lacks context about prerequisites or typical scenarios for standalone container creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deploy-composeC

Deploy a Docker Compose stack

ParametersJSON Schema

Name	Required	Description	Default
`compose_yaml`	Yes
`project_name`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Deploy' implies a write/mutation operation, but doesn't disclose critical traits like whether it's idempotent, requires specific permissions, destroys existing resources, handles errors, or has rate limits. The description adds no context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single, front-loaded sentence that directly states the tool's purpose. There is zero wasted text, and it efficiently communicates the core function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of deployment operations (mutating system state), no annotations, no output schema, and 0% schema coverage for 2 parameters, the description is incomplete. It lacks essential details like what 'deploy' entails behaviorally, parameter meanings, expected outcomes, or error handling, leaving significant gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'compose_yaml' should contain (e.g., YAML string format), what 'project_name' is used for (e.g., naming containers/networks), or any constraints (e.g., length, characters). With 2 undocumented parameters, this is inadequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Deploy') and resource ('a Docker Compose stack'), making the purpose immediately understandable. It distinguishes from siblings like 'create-container' (single container vs. stack) and 'get-logs'/'list-containers' (read operations vs. deployment). However, it doesn't specify what 'deploy' entails (e.g., creating containers, networks, volumes) beyond the high-level concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., Docker Compose installed), when to choose this over 'create-container' for single-container deployments, or any constraints (e.g., environment compatibility). Usage is implied from the name but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-logsC

Retrieve the latest logs for a specified Docker container

ParametersJSON Schema

Name	Required	Description	Default
`container_name`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose what 'latest logs' means (e.g., time range, log count, format), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool with one parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 low schema coverage, the description is incomplete. It lacks details on return values (e.g., log format, structure), error handling, and behavioral context needed for a logging tool in a Docker environment with siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaning by specifying that 'container_name' is for a Docker container. However, it doesn't clarify parameter details like format, examples, or how it relates to other tools (e.g., if it must match names from 'list-containers'), leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'retrieve' and resource 'latest logs for a specified Docker container', making the purpose evident. It distinguishes from siblings like 'list-containers' by focusing on logs rather than container metadata, though it doesn't explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., container must be running), exclusions, or comparisons with sibling tools like 'list-containers' for container discovery.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-containersB

List all Docker containers

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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 action ('List all') but lacks details on permissions, rate limits, output format, or any constraints (e.g., whether it includes stopped containers). This is a significant gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it highly concise and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It fails to provide necessary behavioral context (e.g., what 'all' entails, response format) or usage guidelines, making it inadequate for a tool that might have hidden complexities despite having no parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but this is acceptable given the schema's completeness, aligning with the baseline of 4 for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List all Docker containers' clearly states the verb ('List') and resource ('Docker containers'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get-logs' which might also list containers but with logs, so it misses full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'create-container' or 'deploy-compose'. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Jan 2, 2026
- Addedcreate-container
- Addeddeploy-compose
- Addedget-logs
- Addedlist-containers

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.3/5.0

Scored 2026-04-18 11:55 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: create-container for creating containers, deploy-compose for deploying stacks, get-logs for retrieving logs, and list-containers for listing containers. The descriptions make it easy to tell them apart.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create-container, deploy-compose, get-logs, list-containers). There are no deviations in naming style or conventions.

Tool Count4/5

With 4 tools, the count is reasonable for a Docker MCP server, covering key operations like creating, listing, and managing containers and stacks. It's slightly lean but well-scoped for basic Docker management tasks.

Completeness3/5

The toolset covers core operations (create, list, logs, deploy) but has notable gaps, such as missing update, delete, or stop/start container tools, which could limit agent workflows for full container lifecycle management.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
Node CommandOAuth
io.github.huseyincig
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
File Systems Shell Access Browser Automation
1

Related MCP Servers

ChatGPT MCP Server
Virtualization Code Execution
Toowiredd
F
license
A
quality
F
maintenance
A Model Context Protocol server that enables Docker container management through natural language interactions using a custom GPT interface.
Updated a year ago (2025-07-22 13:12 UTC)
7
15
-
MCP Development Server
Code Execution Developer Tools Version Control
dillip285
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables Claude to manage software development projects with complete context awareness and code execution through Docker environments.
Updated 2 years ago (2024-12-15 06:22 UTC)
18 npm
4
-
Docker MCP Server
Virtualization Developer Tools Command Line
suvarchal
A
license
A
quality
F
maintenance
Allows Claude and other AI assistants to interact with Docker through the MCP protocol, enabling container and image management including listing, running, stopping, and pulling Docker resources.
Updated 2 years ago (2025-03-13 01:11 UTC)
6
76 npm
4
MIT
Docker Build MCP Server
Command Line Virtualization Developer Tools
ekdh600
F
license
Not graded
quality
D
maintenance
A TypeScript server that fully implements the Model Context Protocol (MCP) standard, providing API access to Docker CLI operations like build, run, stop, and image management through compatible AI clients.
Updated a year ago (2025-06-30 05:46 UTC)
-

🐳docker-mcp

✨ 特点

🎬 演示

部署 Docker Compose 堆栈

分析容器日志

🚀 快速入门

通过 Smithery 安装

先决条件

安装

Claude桌面配置

🛠️ 开发

本地设置

🔍 调试

📝 可用工具

创建容器

部署-撰写

获取日志

列表容器

🚧 当前限制

🤝 贡献

📜 许可证

✨ 作者

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches