Your Agent Wants to Restart a Container. What Do You Hand It?
You’ve got Komodo running your homelab. You’ve got an LLM that’s annoyingly good at reading logs and diagnosing why postgres keeps restarting. The obvious next move is to let the model act instead of just talk. So you open a terminal and start typing a docker run command with -v /var/run/docker.sock:/var/run/docker.sock, because that’s what every tutorial does.
Stop. That single flag hands the model root on your host. A community MCP server for Komodo does the same diagnostic job through a narrow, auditable HTTP API: scoped credentials, per-tool permissions, and a confirmation prompt before anything destructive runs. That is the argument, and it has nothing to do with chat being a fun way to talk to your server rack. It’s about what surface you’re exposing and who gets to call what on it.
Before you get excited, sit with the catch: the MCP server in question isn’t something the Komodo team ships. It’s a third-party project with 33 GitHub stars as of September 2026, built by someone who isn’t on the Komodo core team, running with credentials that can restart, redeploy, and destroy anything in your fleet. You’re not removing risk. You’re trading one large risk (an open socket) for one smaller, better-shaped risk (a small dependency with a well-designed permission model). That trade is worth making. Just don’t pretend it’s free.
What Komodo Actually Is
Komodo (github.com/moghtech/komodo, GPL-3.0, Rust, 12,344 stars as of September 2026) is a container and server management tool built from two pieces. Komodo Core is the web UI and API, backed by MongoDB, listening on port 9120 by default. Komodo Periphery is the agent you run on every host you want managed. Periphery is what actually mounts /var/run/docker.sock, along with /proc, out of a root directory that defaults to /etc/komodo.
That matters for the argument that follows. Periphery touching the socket is fine. It is a fixed, compiled binary from a project with over 12,000 stars, doing one job, with no ability to interpret arbitrary instructions. The thing you’re about to hand a socket to in the lazy setup is a language model that will cheerfully follow whatever text it’s fed, including text from a poisoned README, a scraped log line, or a prompt injected through a webhook payload it was told to summarize.
Komodo organizes everything into resources: Servers, Stacks, Deployments, Builds, Repos, Procedures, Actions, Alerters, Builders, Resource Syncs, Variables, and Tags. Every one of those is a candidate for an AI agent to poke at, which is exactly why the shape of the API in front of them matters more than whether the interface is a chat window or a CLI.
The Lazy Way: Handing Over the Keys
Mounting the Socket
Give an agent container write access to /var/run/docker.sock and you’ve given it the ability to start a new container that bind-mounts / from the host and chroots into it. From there it owns the box. It doesn’t need a vulnerability. It just needs to run docker, which is the one thing you told it to do.
This is the forklift-to-move-a-couch problem. Technically the socket gets your logs read and your container restarted. It also lets the same process rewrite /etc/passwd on the host if it decides that’s a reasonable step toward “fixing” a crash loop. Nothing stops it. Nothing asks first.
SSH and a Prayer
The other lazy option is dropping the agent onto the host over SSH with a real shell. Now it can run anything: docker compose down -v, rm -rf, an unattended apt upgrade at 2 AM. There’s no tool boundary, no scope, and no log of intent, only a shell history that records commands, not reasoning. If the agent runs docker volume prune -f because it misread a support forum post you pasted into context, you find out when your Postgres data is gone.
Neither of these setups asks the model to justify a destructive action before it happens. That’s the actual gap the MCP approach closes.
The Narrower Path: Komodo MCP Server
The most developed option in this space is komodo-mcp-server (github.com/MP-Tool/komodo-mcp-server), TypeScript, GPL-3.0, 33 stars as of September 2026, currently at 1.5.0 (released 2026-08-11), also published to npm as komodo-mcp-server. It needs Komodo Core 2.x and Node.js 22+ if you’re not running it in Docker, and it refuses to expose version-sensitive tools like komodo_exec against an older core rather than guessing.
It never touches your hosts directly, only Komodo Core’s existing HTTP API, using credentials you issue. Core is the thing that already talks to Periphery. The agent never gets closer to your Docker daemon than an API key does.
The README lists 88 distinct komodo_* tools across 20 categories. Its own “Available Tools (69)” sub-heading is stale, so count the table rather than the label. Categories include config, container, server, stack, deployment, build, repo, procedure, action, alerter, swarm, resource_sync, variable, update, terminal, user, docker, builder, tag, and toml. Real tools you’ll actually call: komodo_server_list, komodo_container_list, komodo_container_inspect, komodo_container_logs, komodo_container_action for start/stop/restart/pause, komodo_stack_action for deploy/pull/destroy, komodo_exec for a shell scoped to a server, container, deployment, or stack service, and komodo_update_list / komodo_update_info for history.
Two Layers of Auth, Not One
There are two separate credentials in play, and conflating them is how people misconfigure this.
The MCP server authenticates to Komodo using one of three methods: KOMODO_API_KEY plus KOMODO_API_SECRET (the documented recommendation), KOMODO_USERNAME plus KOMODO_PASSWORD, or a KOMODO_JWT_TOKEN. KOMODO_URL is required in every case and needs a full scheme, host, and port, like https://komodo.example.com:9120. All of these support Docker secrets through *_FILE variants, so KOMODO_API_KEY_FILE=/run/secrets/komodo_api_key keeps the value out of your environment listing entirely.
Separately, people signing in to the MCP server itself over HTTP or HTTPS has been on by default since 1.5.0. Each person authenticates with their own Komodo username and password and gets their own permission set, rather than everyone sharing one blanket credential. Set MCP_AUTH_ENABLED=false and you get a read-only server: every write, exec, or delete tool, including komodo_exec, disappears from tools/list and gets rejected outright. Startup logs a READ-ONLY notice so you can’t miss it. stdio transport is local-only and skips this layer since there’s no network client to authenticate.
If you want a safe way to let an agent poke around your fleet without any chance of it touching anything, MCP_AUTH_ENABLED=false over HTTP is the answer, and it costs you nothing to set up.
services: komodo-mcp-server: image: ghcr.io/mp-tool/komodo-mcp-server:latest restart: unless-stopped security_opt: - no-new-privileges:true ports: - 8000:8000 environment: MCP_TRANSPORT: http KOMODO_URL: https://komodo.example.com:9120 KOMODO_API_KEY_FILE: /run/secrets/komodo_api_key KOMODO_API_SECRET_FILE: /run/secrets/komodo_api_secret deploy: resources: limits: memory: 256M cpus: '0.5'That’s close to the compose file shipped in the repo itself. The upstream version also sets TZ, points MCP_CONFIG_FILE_PATH at /app/config.toml, and loads an .env file. The 256M / 0.5 CPU limits (with 128M / 0.1 reservations) are the documented defaults, not a guess.
Destructive Actions Have to Ask First
Deletes, destroys, prunes, and komodo_exec calls go through MCP elicitation before they run: the server asks the human on the other end to confirm, with a checkbox in the loop, not just a free-text “yes.” If the connected client can’t present that prompt, the call fails closed instead of running unconfirmed. MCP_CONFIRM_DESTRUCTIVE and MCP_CONFIRM_FALLBACK control the behavior if you need to tune it, but the default is the safe one.
This is the single biggest functional gap between this setup and either lazy alternative. Neither a mounted socket nor an SSH shell has a concept of “pause and ask” built in. You’d have to build that yourself, and nobody does, because building a confirmation layer for a shell is its own small project.
Every tool also carries a _meta.category and a requiredScopes array of komodo:read, komodo:operate, or komodo:admin. That three-tier split is what an MCP gateway or a reverse proxy can gate on if you want per-user policy on top of what the server already enforces.
Pruning the Tool List Before It Ever Loads
This also solves a cost problem you didn’t ask about: every tool definition you register with a model eats context tokens on every single call, whether the model uses it or not. Loading all 88 tools into a small local model’s context is wasteful if that agent only ever needs to read logs.
MCP_TOOLS_ALLOWED_CATEGORIES, MCP_TOOLS_EXCLUDED_CATEGORIES, and MCP_TOOLS_EXCLUDED_TOOLS cut the list before the client ever sees it. Want a log-reading assistant that can never restart anything? Exclude the container, stack, deployment, and terminal categories and those tools vanish from tools/list entirely, gone rather than merely hidden behind a permission check. Want to keep everything except shell access specifically? Drop komodo_exec by name in MCP_TOOLS_EXCLUDED_TOOLS and keep the rest.
MCP_TOOLS_EXCLUDED_CATEGORIES=terminalMCP_TOOLS_EXCLUDED_TOOLS=komodo_exec,komodo_stack_actionThis is purely subtractive. It never grants more than the underlying Komodo credential already allows, and a typo in a category name just logs a startup warning and gets ignored, it doesn’t silently unlock anything.
Getting It Running
For Claude Desktop or any stdio-based client, skip the network layer entirely:
"komodo-mcp-server": { "command": "docker", "args": [ "run", "-i", "--rm", "-e", "KOMODO_URL=https://komodo.example.com:9120", "-e", "KOMODO_API_KEY=api-key", "-e", "KOMODO_API_SECRET=api-secret", "ghcr.io/mp-tool/komodo-mcp-server:latest" ]}Once the HTTP server from the compose file above is up, poke it with the official inspector before you trust it with anything:
npx @modelcontextprotocol/inspector --url http://localhost:8000/mcpUse /mcp for Streamable HTTP, /sse if you’re stuck on the legacy SSE transport for an older client. Check komodo_health_check first; it reports server version, Komodo connectivity, and current auth status in one call, which beats guessing why tools/list came back empty.
The Audit Trail You Get for Free
Every action the MCP server takes through Komodo shows up in Komodo’s own update history, queryable with komodo_update_list and komodo_update_info. Nobody built that for this use case. Komodo already logs every deploy, restart, and destroy the same way it logs one triggered from the web UI. Hand the same box SSH access instead and your audit trail is a shell history file with no record of why any command ran, and no way to tell “the agent decided this” from “I typed this half asleep.”
The server also runs Zod validation on every input, rate limits requests, has DNS rebinding protection and Helmet security headers on the HTTP transport, and redacts secrets from every tool result centrally, including exec output and log dumps, so a leaked credential in a container’s environment doesn’t ride back out through a tool response. Its own README notes AI tools were part of its development workflow with manual review, worth mentioning plainly given the subject of this article, and not a reason on its own to avoid it.
The Rest of the Field
It is a crowded little corner. At least nine independent community MCP servers for Komodo were on GitHub as of September 2026, and the MP-Tool one above has the most stars of any of them at 33. The runners-up thin out fast: MyrikLD/komodo-mcp (Python, 15 stars), Nonetss/komodo-mcp (TypeScript, 10 stars), Samik081/mcp-komodo (TypeScript, MIT, 6 stars), and nicolasestrem/komodo-mcp (TypeScript, Apache-2.0, 4 stars), plus a handful sitting at zero stars, one of them already archived.
Star counts are a weak signal, so use a harder one first: check the license. MyrikLD/komodo-mcp and Nonetss/komodo-mcp both ship with no license file at all, which makes them a legal gray area you don’t want holding fleet-level credentials, whatever the code quality. No license, no install. That filter alone drops four of the nine before you read a line of source.
The Verdict, Again
You’re still trusting a small, community-maintained dependency with meaningful power over your infrastructure. That’s real and worth sitting with before you deploy it. The alternative is a wide open socket or an unbounded shell with zero of the scoping, confirmation, or audit trail this server gives you by default. Run it with MCP_AUTH_ENABLED on, issue scoped API keys per agent, prune the tool categories down to what each agent actually needs, and let the confirmation prompts do their job. Your 2 AM self will appreciate not finding out the hard way what “destroy” means to a model that misread a log line.
Common Questions
Does Komodo have an official MCP server?
No. Komodo’s maintainers (moghtech) ship Core and Periphery only. The MCP server covered here, komodo-mcp-server from MP-Tool, is an independent community project with 33 GitHub stars as of September 2026, not an official Komodo release, and it carries its own separate license and support expectations.
Can I run the Komodo MCP server in read-only mode?
Yes. Set MCP_AUTH_ENABLED=false on the HTTP transport and the server drops every write, exec, and delete tool from tools/list, including komodo_exec, and rejects calls to them outright. Startup logs a READ-ONLY notice so the state is visible immediately, not discovered later.
What’s the minimum Komodo and Node.js version for the MCP server?
Komodo Core 2.x and Node.js 22+ if you run the server outside Docker. Version-sensitive tools like komodo_exec get disabled automatically against an older Core rather than failing unpredictably at call time. Running the official Docker image sidesteps the Node requirement entirely.
Do I still need Komodo Periphery on every host?
Yes. The MCP server only talks to Komodo Core’s HTTP API; it never reaches a managed host directly. Periphery still has to run on each server you want Komodo to control, mounting /var/run/docker.sock and /proc there exactly as it does without any MCP server in the picture.
Does the Komodo MCP server work with Podman instead of Docker?
Yes, indirectly. The Komodo MCP server only talks to Komodo Core over HTTP, so it has no direct dependency on Docker or Podman. What matters is whether Komodo Periphery on your hosts supports Podman; the MCP layer just inherits whatever Periphery already manages underneath it.
