Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/l337-org/docker-mcp/l337-dockernpx skills add L337-org/docker-mcp --skill l337-dockergit clone --depth 1 https://github.com/L337-org/docker-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/l337-org/docker-mcp/l337-docker)<a href="https://agentmods.dev/skills/l337-org/docker-mcp/l337-docker"><img src="https://agentmods.dev/badge/skills/l337-org/docker-mcp/l337-docker.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00131 | $0.03012 |
| Opus 5 | $0.00066 | $0.01506 |
| Sonnet 5 | $0.00026 | $0.00602 |
| Haiku 4.5 | $0.00013 | $0.00301 |
Grade A, and why
l337-docker scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
`docker`, its subcommands, and (for registry queries that need no daemon) `curl` against the How it starts
The opening of the file, as written. The whole thing — 222 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Docker via the CLI
Every operation here goes through the docker binary and its plugins. No SDK, no daemon library -
docker, its subcommands, and (for registry queries that need no daemon) curl against the
registry HTTP API.
This file is the router. It carries the rules that apply to every Docker operation plus a map
into reference/ (how to do a thing) and workflows/ (multi-step procedures). Read the one
reference file the task needs - not all of them.
Preflight
Run once at the start of a Docker session, before anything else:
docker version --format '{{.Server.Version}} (API {{.Server.APIVersion}})' # daemon reachable?
docker context ls --format json # which daemon, and what else is configured
docker system info --format '{{.Name}} {{.OperatingSystem}} {{.Swarm.LocalNodeState}}'
If the daemon is unreachable, say so and stop - do not fall back to guessing state from
config files. The common causes are Docker Desktop not running (macOS/Windows), the user not
being in the docker group (Linux), or DOCKER_HOST/DOCKER_CONTEXT pointing somewhere dead.
Check plugins only when the task needs one - compose, buildx and scout are separate
binaries and are frequently absent on servers:
docker system info --format '{{range .ClientInfo.Plugins}}{{.Name}} {{end}}'
A missing plugin is a hard stop for that domain, not something to work around by hand-rolling the equivalent. Say which plugin is missing and what installs it.
Rules that always apply
1. Read before you write. Inspect current state before changing it, and show the user what you found. Most Docker mistakes are irreversible in the way that matters (a removed volume, a clobbered tag), and the read costs nothing.
2. Bound every output. The CLI streams without limit and will flood the context window. There is no server truncating for you.
- Logs: always
--tail N(start at 100-200). Never baredocker logs. docker stats: always--no-stream. Without it, it never returns.docker events: never bare - it streams forever. Bound it with--until 0sfor history, or a future epoch to wait (--until $(($(date +%s)+300))).--until nowis invalid.- Anything large (image save, container export, archives): write to a file, never into the context. Then report the path and size.
- Projecting fields with
--formatbeats piping a full dump throughhead.
What ships with it
17 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- LICENSE 1.0 KB
- reference/buildx.md 6.3 KB
- reference/compose.md 8.3 KB
- reference/containers.md 9.4 KB
- reference/docs.md 3.6 KB
- reference/images.md 7.6 KB
- reference/networks-volumes.md 5.7 KB
- reference/observability.md 9.2 KB
- reference/registry.md 6.7 KB
- reference/scout.md 5.4 KB
- reference/swarm.md 11 KB
- reference/system.md 12 KB
- workflows/build-publish.md 5.9 KB
- workflows/deploy.md 6.2 KB
- workflows/maintenance.md 9.1 KB
- workflows/security.md 6.2 KB
- workflows/troubleshoot.md 8.4 KB
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 222 lines · 131 tokens per session scan A d88bdc65903e
l337-docker is a skill published in the GitHub repository L337-org/docker-mcp (4 stars, last pushed today), licensed MIT. It adds 131 tokens to every session and 3,012 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
harbor
CLI toolkit for managing containerized LLM services. Use when the user wants to start, stop, configure, or manage AI/LLM services like Ollama, Open WebUI, llama.cpp, vLLM, LiteLLM, ComfyUI, and 250+ others. Triggers on requests to "run a model", "start ollama", "set up an LLM", "configure harbor", "manage services"…
new-service
Add a new service to Harbor — scaffold the compose config, environment variables, metadata, documentation, and cross-service integrations. Use this skill whenever the user wants to add a new service to Harbor, integrate a new tool/app/model server, create a compose configuration for a new project, or onboard any…
docker-local-build
Build and test Kurtosis from source on local Docker. Compiles all components (engine, core, files-artifacts-expander), builds Docker images, installs the CLI, and restarts the engine. Use when developing Kurtosis and testing changes locally with Docker.
k8s-dev-deploy
Build, push, and deploy Kurtosis dev images to a Kubernetes cluster without creating a release. Rebuilds engine, core, and files-artifacts-expander as multi-arch Docker images with a unique tag, pushes to the logged-in user's Docker Hub, and restarts the engine. Use when testing local code changes on a k8s cluster.
docker-debug
Debug Kurtosis running on local Docker. Inspect engine, API container, and service logs. Diagnose container crashes, port conflicts, and networking issues. Use when kurtosis commands fail or services aren't reachable on Docker.
k8s-debug-pods
Debug Kurtosis pods on Kubernetes. Diagnose why pods are Pending, CrashLoopBackOff, ImagePullBackOff, or Evicted. Check node taints, tolerations, resource pressure, and pod events. Use when kurtosis engine start fails or pods aren't coming online.