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가 설치되어 실행 중입니다.
지엑스피1
이 저장소를 복제하세요
종속성 설치:
cd docker-mcp
npm install프로젝트를 빌드하세요:
npm run builddocker-mcp-server또는 소스에서 설치한 경우:
npm start포함된 설치 스크립트를 사용하면 Claude로 Docker MCP 서버를 자동으로 구성할 수 있습니다.
npm run install-config이 스크립트는 다음을 수행합니다.
Claude 설치(데스크톱 및/또는 VSCode) 감지
Docker MCP 서버를 포함하도록 구성 파일을 업데이트합니다.
시스템에 맞는 올바른 경로를 설정하세요
수동으로 구성하려면 MCP 설정 구성 파일에 Docker 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 서버를 구성한 후 Cline에 변경 사항을 적용하려면 VS Code를 다시 시작해야 할 수 있습니다. Cline에서 Docker MCP 서버가 인식되지 않거나 제대로 작동하지 않는 문제가 발생하면 VS Code를 다시 시작해 보세요.
모든 Docker 컨테이너를 나열합니다.
매개변수:
all (부울, 선택 사항): 모든 컨테이너 표시(기본값은 실행 중인 컨테이너만 표시)
모든 Docker 이미지를 나열합니다.
Docker 컨테이너를 실행합니다.
매개변수:
image (문자열, 필수): 실행할 Docker 이미지
name (문자열, 선택 사항): 컨테이너의 이름
detach (boolean, 선택 사항): 컨테이너를 백그라운드에서 실행합니다.
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 마켓플레이스에 대한 자세한 내용은 다음을 방문하세요.
MIT
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.
