list_hostsLABSCO SUMMARY
Read-only by construction, not by policy.
The notable part is not that a dashboard grew an MCP endpoint — it is that the endpoint ships no write tools, so an agent can ask which host is lowest on RAM or what is filling /backup and there is nothing there for it to change. Weigh that against what the container itself carries: host access, a read-write Docker socket, and a dashboard with no login, which is why the project tells you to keep it off the public internet.
What it is
A single-page monitor for a home lab — GPU state, power turned into money, containers, systemd services, disks, uptime checks — with a read-only MCP server built into the same container. The dashboard runs on :9800 and the MCP server on :9810, and one line points a client at it: claude mcp add --transport http homelab http://<YOUR_HUB>:9810/mcp. Remote machines are reached over SSH with nothing installed on them; the hub pipes a small self-contained probe over the connection and nothing persists on the far end. Version 0.17.0, MIT licensed.
What you get
- 19 named tools over one HTTP endpoint, covering what the dashboard shows: hosts, containers, systemd services, GPU and who is driving it, per-process RAM, AI model servers, installed models, costs, experiment runs, model benchmarks, disk treemaps, history and alerts
- No write tools at all — the MCP surface is read-only, and
ENABLE_MCP=0removes it entirely - GPU detail past the utilisation number:
nvidia-smithrottle reasons decoded, memory-bandwidth util, core and memory clocks, power against limit, p-state and fan speed, per card, on every machine in the fleet rather than only the one running the container - AMD GPUs read on Linux straight from the kernel's
amdgpuinterface with no ROCm, and AMD and Intel GPUs on Windows hosts; anything a driver will not report says so instead of drawing a zero - Power priced per machine, per component (GPU via
nvidia-smi, CPU and DRAM via RAPL) and per process, container or model, with day and night tariffs and a 7×24 busy-hours heatmap - Benchmark Lab: loads each of your local ollama models, sweeps context sizes on your own cards, and records generation and prompt tokens/sec, load time, how much spilled from VRAM into system RAM, and the largest context that still fits fully in VRAM
- Disk treemaps on any host in the fleet, network I/O with per-container top talkers, and a mini-htop for who is eating CPU and RAM
- Uptime monitoring in the box — any HTTP endpoint or TCP port, with anti-flap confirm, recovery reported with downtime, and an optional slow-response warning
- Edge-triggered push alerts to Discord, ntfy.sh and Telegram, and a standard
/metricsendpoint if you already run Prometheus
Requirements
Docker with Compose: fetch the compose file, docker compose up -d, and open http://<your-host>:9800. No GPU is needed — the GPU panels light up when one is present. Remote hosts need only SSH plus Python 3, or PowerShell on Windows, and the hub's auto-generated key pasted in. The MCP server is on by default at MCP_PORT 9810 and switched off with ENABLE_MCP=0. The registry package runs /app/mcp_server.py under python from the docker.io/sikamikaniko123/homelab-monitor:0.17.0 image over stdio, and requires HOMELAB_MONITOR_URL, the base URL of the running dashboard such as http://YOUR-HUB:9800; MCP_TRANSPORT selects stdio or http. Know what the container holds before you place it: this is a host monitor with host access, a read-write Docker socket and D-Bus socket and a read-only root mount, and the dashboard itself has no login — keep it behind your LAN, VPN or firewall. ALLOW_SELF_UPDATE=0 and ENABLE_CONTROLS=0, or docker-compose.readonly.yml, reduce it to pure monitoring.
Setup effort
Follow the published steps — curl -fsSLO https://raw.githubusercontent.com/SikamikanikoBG/homelab-monitor/main/docker-compose.yml
USE CASES
Finding out what is actually holding the GPU
Ask which model server is loaded and who is calling it; the answer covers every card in the fleet, with the per-card VRAM split rather than one pooled number.
Chasing down what filled a disk
Ask for the biggest folders on a path and flag anything that looks like runaway logs — remote hosts are scanned over the same SSH connection, with nothing installed on them.
Planning a reboot window across several boxes
Ask which host most needs its OS upgrade and what a safe order would be given what is running on each, instead of opening a tab per machine.
Putting a number on what a training run cost
Runs come back with the loss curve and the GPU energy they burned on the same timeline, so "was that worth it" has an answer in money.
19 tools
Listed in project docs. Your client may show a different list.
get_hostget_snapshotget_containersget_servicesget_memoryget_gpuget_ai_modelsget_installed_modelsget_historyget_costsget_entity_costget_experimentsget_experimentget_benchmarksget_benchmarkget_eventsget_alertsscan_diskBEFORE YOU INSTALL
What to know first
Tools you get
19 tools named in the project's documentation.
Requires
Docker with Docker Compose
INSTALLATION
Connect your client
Server setup
curl -fsSLO https://raw.githubusercontent.com/SikamikanikoBG/homelab-monitor/main/docker-compose.yml
docker compose up -d
claude mcp add --transport http homelab http://<YOUR_HUB>:9810/mcpMCP Clients
Claude Code
claude mcp add --transport http homelab http://<YOUR_HUB>:9810/mcp