Loading ToolBench
Docker Model Context Protocol (MCP) Server provides an interface for AI models to manage Docker containers, images, and networks.
The Docker MCP server provides 15 tools with generally adequate naming and descriptions, but exhibits significant gaps in schema completeness, parameter constraints, and error handling guidance. Tool names follow verb_noun convention appropriately (list_containers, exec_command, etc.), and descriptions are present for all tools and most parameters. However, parameter schemas lack proper type definitions in several cases, descriptions are sometimes generic without actionable detail, and output schemas are not documented. The server provides no guidance on error recovery, lacks input validation constraints (enums, ranges), and provides no tool annotations. For a domain-specific tool (Docker), the definitions are serviceable but fall short of production-grade quality.
Build an image from a Dockerfile.
Create a new Docker container from an image. Requires image name and container configuration.
Execute a shell command in a specified container. Requires container_id and command parameters. Returns command output.
Return detailed information about a container.
Return detailed information about an image.
List all running Docker containers with their IDs, names, images, and status. Returns array of container objects.
List all locally stored Docker images. Returns array of image objects with ID, tags, size and creation time.
Output schemas not documented. No description of what fields each tool returns, their types, or how to chain results between tools. This forces LLMs to guess at response structure.
No error handling guidance. Tools provide no recovery hints (e.g. 'Image not found. Try pull_image() first.'). Errors will likely be raw API failures with no actionable next steps for the LLM.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Get logs from a container.
Pull Docker image from registry. Requires image_name parameter (format: name:tag). Returns streaming progress updates.
Remove one or more containers.
Remove one or more images.
Restart a container.
Search for Docker images on Docker Hub. Returns array of image results including name, description, official status, and star count.
Start one or more stopped containers.
Stop a running container.
Missing input constraints. Parameters like 'timeout' (numeric) lack min/max bounds. Parameters like 'restart_policy' and 'network_mode' should declare valid enum values but instead accept free-form strings, risking invalid Docker API calls.
Generic parameter descriptions. 'Container ID or name to start' is clear, but descriptions for complex parameters like 'ports' and 'volumes' in create_container only state the format ('host_port:container_port/protocol') without explaining what happens if the format is wrong or how to choose defaults.
Destructive operations lack confirmation. remove_container and remove_image perform irreversible deletions with no dry-run or confirmation option. An LLM could accidentally delete critical infrastructure.
No tool annotations. Missing readOnlyHint, destructiveHint, and idempotentHint annotations that would help LLMs reason about side effects and retry safety.
Parameter dependencies undocumented. create_container has many optional parameters (env, ports, volumes, network_mode, restart_policy) whose valid values and interactions are not explained. An LLM cannot determine which combinations are sensible.
No pagination support for list tools. list_containers and list_images accept no limit or offset parameters. On systems with thousands of containers/images, results could explode the context window or time out.
search tool lacks result limits. Accepts 'limit' with max 100, but provides no guidance on what 'limit' actually controls or how many results are returned by default. Description says 'default: 25' but does not explain if that means 25 results or 25 pages.