Provides tools for managing Docker containers and images, including listing containers and images, running containers with customizable options, stopping and removing containers, and pulling images from registries.
Mentioned as an example image that can be pulled and run as a container with port mapping.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Docker MCP Server list all Docker containers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Docker operations. This server allows Claude and other AI assistants to interact with Docker through the MCP protocol.
Note: This MCP server works with standard Docker CLI commands and does not currently support Docker Compose operations, other MCP servers with docker-compose didn't work reliably with cline yet.
List Docker containers
List Docker images
Run Docker containers
Stop running containers
Remove containers
Pull Docker images from registries
Related MCP server: Docker MCP Server
Node.js 18 or higher
Docker installed and running on your system
npm install -g docker-mcp-serverClone this repository
Install dependencies:
cd docker-mcp
npm installBuild the project:
npm run builddocker-mcp-serverOr if installed from source:
npm startYou can use the included installation script to automatically configure the Docker MCP server with Claude:
npm run install-configThis script will:
Detect your Claude installations (Desktop and/or VSCode)
Update the configuration files to include the Docker MCP server
Set up the correct paths for your system
If you prefer to configure manually, you need to add the Docker MCP server to your MCP settings configuration file:
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"docker-mcp": {
"command": "node",
"args": ["/path/to/docker-mcp/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}Edit ~/.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": []
}
}
}Note: After configuring the Docker MCP server in VS Code, you may need to restart VS Code for the changes to take effect in Cline. If you encounter issues with the Docker MCP server not being recognized or working properly in Cline, try restarting VS Code.
List all Docker containers.
Parameters:
all (boolean, optional): Show all containers (default shows just running)
List all Docker images.
Run a Docker container.
Parameters:
image (string, required): Docker image to run
name (string, optional): Name for the container
detach (boolean, optional): Run container in background
ports (array of strings, optional): Port mappings (e.g. ["8080:80"])
volumes (array of strings, optional): Volume mappings (e.g. ["/host/path:/container/path"])
env (array of strings, optional): Environment variables (e.g. ["KEY=value"])
command (string, optional): Command to run in the container
Stop a running Docker container.
Parameters:
container (string, required): Container ID or name
Remove a Docker container.
Parameters:
container (string, required): Container ID or name
force (boolean, optional): Force removal of running container
Pull a Docker image from a registry.
Parameters:
image (string, required): Image name (e.g. "nginx:latest")
Once configured, you can ask Claude to perform Docker operations:
"Run a hello-world Docker container"
"List all Docker containers"
"Pull the latest nginx image"
"Run an nginx container on port 8080"
"Stop the nginx container"
"Remove all stopped containers"
This Docker MCP server is available on the Cline MCP Marketplace, making it easy for users to discover and install with one click.
The logo for the MCP Marketplace submission is located in the assets/logo.png file.
For more information about the MCP Marketplace, visit:
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.
