Loading ToolBench
MCP server that exposes Docker Compose best practices, troubleshooting guides, hardened recipes, helper scripts, and the annotated compose template as tools. All file contents are read dynamically from disk.
This server exposes 11 read-only file-serving tools with clear, action-oriented names (get_*, list_*) and reasonable descriptions. However, schema completeness and parameter documentation are inconsistent. Most tools accept zero or one parameter, which limits complexity but also limits validation opportunities. Descriptions are moderately detailed (100-250 chars, within baseline), but several lack explicit guidance on WHEN to use the tool vs alternatives. No error handling guidance, no output schemas documented, and no tool annotations. The server is functional for its narrow use case (documentation delivery) but lacks production-grade polish.
Check a docker-compose.yml snippet against field guide standards. Does not write to disk or run Docker commands.
Load the full best practices guide (BEST-PRACTICES.md). Covers 21 sections: image pinning, resource limits, security hardening, healthchecks, secrets management, network isolation, logging, YAML anchors, dependency ordering, and more. Use this as the primary reference when building or auditing compose stacks.
Load the Docker Compose coding standards from CLAUDE.md. Returns the compose rules that every docker-compose.yml must follow: image pinning, resource limits, security defaults, healthchecks, log rotation, network isolation, and the validation workflow. Call this before writing or reviewing any compose file.
Load the annotated docker-compose.yml reference template. A fully commented compose file demonstrating every best practice: YAML anchors, security defaults, resource limits, healthchecks, secrets, network isolation, and dependency ordering. Copy and adapt this template when starting a new stack.
Load a specific documentation guide by filename.
Parameterized get_* and list_* tools (get_guide, get_recipe, get_script) lack input schema documentation in the visible source. The 'filename' parameter is described in the docstring but no JSON Schema type/format is visible. LLMs cannot validate inputs or infer format constraints.
check_compose_text has a 'text' parameter but no documented output schema. The tool description says it 'does not write to disk or run Docker' (read-only), but what does it RETURN? Does it return pass/fail, violations list, or raw output? LLMs cannot plan chained calls without knowing the response structure.
No error handling guidance. Tools that read files (get_guide, get_recipe, get_script) silently return '[file not found: ...]' strings on missing files. These are not structured errors, LLMs may not recognize them as failures and might loop retrying. No recovery guidance (e.g., 'Call list_guides() to see available files').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Load a specific hardened Docker Compose recipe.
Load a specific Docker helper script.
Load the troubleshooting and debugging playbook. Step-by-step diagnostic workflow for common Docker Compose failures: container won't start, unhealthy status, networking issues, volume permission errors, OOM kills, and more.
List all available documentation guides. Returns the filenames and first-line titles of all Markdown files in the docs/ directory. Use get_guide() to retrieve a specific one.
List available hardened Docker Compose recipes. Returns the filenames of all .yml recipe files in the recipes/ directory. Each recipe is a production-ready compose stack for a popular homelab application. Use get_recipe() to retrieve one.
List available Docker helper scripts. Returns the filenames and first-line descriptions of shell scripts in the scripts/ directory. These cover disk reporting, cleanup, and safe reset operations. Use get_script() to retrieve one.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 11 tools are read-only and idempotent, but this is not explicitly declared in the schema. Clients and LLMs cannot infer these safety properties.
No output schemas documented. Each tool returns a string, but what is the structure, encoding, or length limit? The best-practices guide is described as covering '21 sections' but the output schema does not specify this. LLMs cannot anticipate context window impact or parse structured sub-fields.
Discovery tools (list_guides, list_recipes, list_scripts) lack guidance on how to use results. Should the LLM call get_guide() immediately after list_guides()? Or are the descriptions in the list sufficient? The dependency chain is implicit, not documented.