Un servidor de Protocolo de Contexto de Modelo (MCP) para operaciones de Docker. Este servidor permite a Claude y a otros asistentes de IA interactuar con Docker mediante el protocolo MCP.
Nota: Este servidor MCP funciona con comandos CLI de Docker estándar y actualmente no admite operaciones de Docker Compose; otros servidores MCP con docker-compose aún no funcionaban de manera confiable con cline.
Lista de contenedores Docker
Lista de imágenes de Docker
Ejecutar contenedores Docker
Detener el funcionamiento de los contenedores
Retirar los contenedores
Extraer imágenes de Docker de los registros
Related MCP server: Docker MCP Server
Node.js 18 o superior
Docker instalado y ejecutándose en su sistema
npm install -g docker-mcp-serverClonar este repositorio
Instalar dependencias:
cd docker-mcp
npm installConstruir el proyecto:
npm run builddocker-mcp-serverO si se instala desde la fuente:
npm startPuede utilizar el script de instalación incluido para configurar automáticamente el servidor Docker MCP con Claude:
npm run install-configEste script hará lo siguiente:
Detecta tus instalaciones de Claude (Escritorio y/o VSCode)
Actualice los archivos de configuración para incluir el servidor Docker MCP
Configure las rutas correctas para su sistema
Si prefiere configurarlo manualmente, debe agregar el servidor Docker MCP a su archivo de configuración de MCP:
Editar ~/Library/Application Support/Claude/claude_desktop_config.json :
{
"mcpServers": {
"docker-mcp": {
"command": "node",
"args": ["/path/to/docker-mcp/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}Editar ~/.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": []
}
}
}Nota: Después de configurar el servidor Docker MCP en VS Code, es posible que deba reiniciar VS Code para que los cambios surtan efecto en Cline. Si experimenta problemas porque el servidor Docker MCP no se reconoce o no funciona correctamente en Cline, intente reiniciar VS Code.
Enumere todos los contenedores Docker.
Parámetros:
all (booleano, opcional): muestra todos los contenedores (el valor predeterminado muestra solo los que se están ejecutando)
Listar todas las imágenes de Docker.
Ejecutar un contenedor Docker.
Parámetros:
image (cadena, obligatoria): imagen de Docker para ejecutar
name (cadena, opcional): nombre del contenedor
detach (booleano, opcional): ejecutar el contenedor en segundo plano
ports (matriz de cadenas, opcional): asignaciones de puertos (por ejemplo, ["8080:80"])
volumes (matriz de cadenas, opcional): asignaciones de volúmenes (por ejemplo, ["/host/path:/container/path"])
env (matriz de cadenas, opcional): variables de entorno (por ejemplo, ["KEY=value"])
command (cadena, opcional): comando para ejecutar en el contenedor
Detener un contenedor Docker en ejecución.
Parámetros:
container (cadena, obligatorio): ID o nombre del contenedor
Eliminar un contenedor Docker.
Parámetros:
container (cadena, obligatorio): ID o nombre del contenedor
force (booleano, opcional): fuerza la eliminación del contenedor en ejecución
Extraer una imagen de Docker de un registro.
Parámetros:
image (cadena, obligatoria): Nombre de la imagen (p. ej., "nginx:latest")
Una vez configurado, puedes pedirle a Claude que realice operaciones de Docker:
"Ejecutar un contenedor Docker de "hola-mundo""
"Enumerar todos los contenedores Docker"
"Obtener la última imagen de nginx"
Ejecutar un contenedor nginx en el puerto 8080
"Detener el contenedor nginx"
"Retirar todos los contenedores detenidos"
Este servidor Docker MCP está disponible en Cline MCP Marketplace, lo que hace que sea fácil para los usuarios descubrirlo e instalarlo con un solo clic.
El logotipo para el envío a MCP Marketplace se encuentra en el archivo assets/logo.png .
Para obtener más información sobre el Mercado MCP, visite:
Instituto Tecnológico de Massachusetts (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.
