Loading ToolBench
MCP server for Docker — manage containers, images, volumes, and compose services from your IDE
The MCP Docker server has 10 tools with consistent verb_noun naming, clear parameter schemas using Zod, and structured output formatting. However, descriptions are brief (averaging ~45 chars), lack WHEN/WHY guidance, and several tools are missing deployment/safety context. Parameters have types and descriptions but lack granular constraints (enums, ranges, formats). Error handling is minimal, no recovery guidance, no invalid-value feedback. Output is text-based rather than structured JSON, forcing LLMs to parse container/image listings. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). The server follows basic tool patterns but falls short of production-grade LLM optimization.
Get logs from a Docker container.
Get CPU, memory, and network stats for a running Docker container.
Execute a command inside a running Docker container.
List Docker containers. Set all=true to include stopped containers.
List Docker images on the host.
Remove a Docker container. Use force=true to remove running containers.
Remove a Docker image. Use force=true to force removal.
Descriptions are uniformly brief (35 - 55 chars) and lack WHEN/WHY context. E.g., 'List Docker containers' does not explain when to call it vs. alternatives, what the LLM should do with the output, or what 'all=true' implies operationally. Pattern recommends 50 - 200 chars with actionable guidance.
Output is plain-text formatted strings (e.g., 'CPU: 42.3%, Memory: 512MB/2GB') instead of structured JSON objects. LLMs must parse unstructured text to extract metrics, risking parse errors and wasting tokens. Pattern recommends returning typed objects: {cpu_percent: 42.3, memory_usage: '512MB', memory_limit: '2GB'}.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Restart a Docker container.
Start a stopped Docker container.
Stop a running Docker container.
No tool annotations despite clear risk stratification. 'remove_container' and 'remove_image' are DESTRUCTIVE but lack destructiveHint. 'list_containers', 'container_logs', etc. are READ_ONLY but lack readOnlyHint. MCP spec 2026-07-28 supports tool annotations to guide LLM safety reasoning. Should annotate all tools.
Parameters lack granular constraints. 'tail' accepts any positive number but should specify range (e.g., 1 - 10000). 'id' accepts any string but should clarify 'container ID (12+ hex chars) or container name (alphanumeric_-)'. 'command' is an array of strings with no length/content validation. Pattern recommends explicit constraints in descriptions.
Error handling is silent/minimal. When a container is not found, exec fails, or a command returns non-zero, no guidance is provided. Should return structured errors with recovery hints, e.g., 'Container "xyz" not found. Call list_containers to find valid IDs.' Pattern recommends recovery-guide classification.
No dry-run or confirmation pattern for destructive operations. 'remove_container' and 'remove_image' can permanently delete data. Pattern recommends a confirm step or dry-run flag to prevent accidental destruction from agent reasoning errors.
'exec_command' accepts arbitrary command arrays with no sanitization visible. LLMs can be prompted to pass malicious payloads (e.g., shell injection, privilege escalation). Should validate command syntax and warn about risky patterns. Pattern recommends tool-gateway input sanitization.
No pagination/result limiting for 'list_containers' and 'list_images'. If a host has hundreds of containers/images, returning all of them bloats output and wastes tokens. Pattern recommends page/offset + limit parameters and total count.