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 "Install 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't describe what the output looks like (e.g., format, fields), whether it's paginated, or any side effects. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and clear schema documentation. Every part of the sentence earns its place by directly stating the tool's function.
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 the lack of annotations and output schema, the description is incomplete for effective use. It doesn't explain what the output contains (e.g., container IDs, statuses), how results are formatted, or any behavioral nuances. For a tool that likely returns structured data, this omission leaves the agent without crucial context for interpreting results.
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 has 100% description coverage, with one parameter ('all') fully documented in the schema. The description adds no additional parameter semantics beyond implying a listing action. Since the schema does the heavy lifting, the baseline score of 3 is appropriate—the description doesn't enhance parameter understanding but doesn't need to compensate for gaps.
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 the verb ('List') and resource ('all Docker containers'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_images' or 'remove_container', but the core action is unambiguous. The description avoids tautology by specifying what is being listed rather than just restating the tool name.
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 description provides no guidance on when to use this tool versus alternatives like 'list_images' or 'remove_container'. It doesn't mention prerequisites, context for usage, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection in a multi-tool environment.
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 provided, so the description carries the full burden. It states 'List all Docker images' but doesn't disclose behavioral traits like whether it returns all images or only local ones, if it requires specific permissions, what the output format is, or if there are rate limits. For a tool with zero annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes directly to understanding the tool's purpose.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'List all' entails (e.g., format, scope, or limitations), which is crucial for a tool that might return complex data. For a tool with no structured support, more context is needed to be fully helpful.
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 has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any gaps.
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 the verb ('List') and resource ('Docker images'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_containers' or 'pull_image', which would require a 5, but it's unambiguous about what it 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 description provides no guidance on when to use this tool versus alternatives like 'list_containers' or 'pull_image'. It lacks context about prerequisites, such as whether Docker must be running, or any exclusions. This leaves the agent to infer usage from the tool name alone.
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 of behavioral disclosure. While 'pull' implies a network operation to fetch an image, it lacks details on permissions needed, whether it overwrites existing images, error handling (e.g., for missing images), or performance aspects like timeouts. This leaves significant gaps for safe and effective use.
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, clear sentence with zero wasted words, making it easy to parse and front-loaded with essential information. It efficiently conveys the core action without unnecessary elaboration, earning full marks for brevity and structure.
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 the lack of annotations and output schema, the description is insufficient for a tool that performs a network operation. It doesn't cover behavioral traits like authentication needs, rate limits, or what happens on success/failure, leaving the agent with incomplete context to invoke it reliably in complex scenarios.
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 the single parameter 'image' well-documented in the schema as 'Image name (e.g., "nginx:latest")'. The description adds no additional semantic context beyond what the schema provides, such as registry defaults or tag conventions, meeting the baseline for adequate but not enhanced parameter understanding.
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 the action ('pull') and resource ('Docker image from a registry'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_images' or 'run_container' which also involve Docker images, leaving room for potential confusion about when to choose this specific tool.
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 description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_images' (for viewing existing images) and 'run_container' (which might implicitly pull images), there's no indication of prerequisites, typical use cases, or distinctions that would help an agent select this tool appropriately in context.
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?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose that removal is destructive (deletes container), potential side effects, permission requirements, or error conditions. The schema hints at 'force' parameter for running containers, but the description doesn't explain this behavior.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's complexity.
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 destructive mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'remove' entails (permanent deletion), return values, error handling, or interactions with sibling tools, leaving significant gaps for agent understanding.
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 parameters are well-documented in the schema. The description adds no additional meaning about 'container' or 'force' parameters beyond what the schema provides, meeting the baseline for high schema coverage.
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 the action ('Remove') and resource ('a Docker container'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'stop_container' or specify what type of removal occurs (deletion vs. stopping).
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 provided on when to use this tool versus alternatives like 'stop_container' or 'list_containers'. The description lacks context about prerequisites (e.g., container must exist) or exclusions (e.g., cannot remove running containers without force).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Run a Docker container' implies a creation/execution operation but doesn't specify if it's idempotent, what happens on failure, whether it requires specific permissions, or how output is handled. This is a significant gap for a tool that likely involves system-level changes.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary elaboration. It's appropriately front-loaded and concise for a straightforward action.
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 the complexity of running a Docker container (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like error handling, resource implications, or return values, leaving critical gaps for agent decision-making.
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 has 100% description coverage, clearly documenting all 7 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter information.
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 'Run a Docker container' clearly states the action (run) and resource (Docker container), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'stop_container' or 'remove_container' beyond the basic verb, missing explicit distinction in scope or purpose.
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 description provides no guidance on when to use this tool versus alternatives like 'list_containers' or 'stop_container'. It lacks context about prerequisites (e.g., needing an image pulled first) or typical use cases, leaving the agent to infer usage from the tool name alone.
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 full burden but only states the basic action. It doesn't disclose behavioral traits such as whether stopping is reversible, if it requires specific permissions, potential side effects (e.g., data persistence), or error conditions (e.g., invalid container ID).
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, front-loaded sentence with zero waste. It efficiently conveys the core purpose without unnecessary words, making it easy to parse quickly.
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 the complexity of a destructive operation (stopping a container) with no annotations and no output schema, the description is incomplete. It lacks critical context like what happens after stopping, return values, or error handling, which are essential for safe tool invocation.
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 the parameter 'container' documented as 'Container ID or name'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 the specific action ('stop') and target resource ('a running Docker container'), distinguishing it from sibling tools like remove_container (deletion) and run_container (starting). It uses precise terminology that aligns with Docker operations.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the container must be running), exclusions (e.g., not for stopped containers), or relationships to siblings like list_containers (to identify containers to stop).
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. Dates show when Glama detected each change.
list_containerslist_imagespull_imageremove_containerrun_containerstop_containerEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/suvarchal/docker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
