HomeLab Monitor

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/sikamikanikobg-homelab-monitor

About

Use cases: monitoring-observability

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools

19 read · 0 write · 0 delete · 1 not yet classified

Secrets

None asked for

Install scripts

None found

Runs as

Docker image

Tools (20)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

• get_ai_models

  AI model servers: which models are loaded, their VRAM use, and who is driving them (caller→server connection-seconds attribution over `range`, e.g. "6h", "24h", "7d"). Answers "why is the GPU pinned, and which service is calling it?".

• get_alerts

  Alias for `get_events` — the monitor's alerts are its edge-triggered events.

• get_benchmark

  Full detail for one benchmark run by `run_id` (from `get_benchmarks`): every measured point per context size — tokens/sec, load time, VRAM/RAM-offload, fit verdict and which GPU the weights landed on — plus the derived summary. An unknown id returns an HTTP 404 error.

• get_benchmarks

  LLM Benchmark Lab results (the Benchmarks tab) — stored, rerunnable benchmarks of the host's local models. Each run measures one model across a context-size ladder: generation & prompt tokens/sec, load time, the VRAM↔RAM split (how much spilled to system RAM), the largest context that still fits fully in VRAM (the recommended cap), a fit verdict, and the energy/cost it burned. Optionally filter by `model`. Answers "which local model is fastest here, what fits in VRAM, and what context size should I cap it to?".

• get_containers

  Full Docker container list (Containers tab): per container name, image, state, health, exposed ports, RAM (`mem_bytes`), VRAM (`vram_bytes`), image disk and uptime — plus the summary counts.

• get_costs

  Power-cost summary (Costs tab): what the machine drew and what it cost over `range`, with the live `tariff`, the `machine` totals (now/energy/cost for today, 7d, 30d and the range) and a ranked `breakdown` of which processes, containers, services and models cost the most. Pass `host` (a registered host's name from list_hosts) to price a remote machine from its own poll history — remotes have no per-process `breakdown` yet. Answers "what did my homelab cost, and what's the biggest line item?".

• get_entity_cost

  Cost drill-down for one process/container/service/model by `name` (use a `kind`/`name` pair from `get_costs`' breakdown; `kind` is optional). Returns its `energy_kwh`, `cost`, `avg_w`/`peak_w` and resource use over `range`. Answers "what did *this* model or container cost me?".

• get_events

  Recent edge-triggered events over `range` (OOM kills, threshold crossings), each with a blame line where one can be attributed, plus derived insights.

• get_experiment

  Full detail for one tracked run by `run_id` (from `get_experiments`): its logged-metric series (the loss curve, and a tokens/sec curve too if logged), the GPU power/util time-series over the run, and the priced energy it burned. An unknown id returns an HTTP 404 error.

• get_experiments

  Tracked training/eval runs (Experiments tab), each priced with the real GPU energy it burned. Optionally filter by `status` (running/finished/failed/killed). Each row carries its params, latest metrics (loss/accuracy…, plus throughput as `tokens_per_sec` when an LLM training script logged it), duration and cost. Answers "which runs ran, how did they do, what did each one cost, and how many tokens/sec were they pushing?".

• get_gpu

  GPU detail: current utilisation, VRAM used/total, power and temperature, plus per-model VRAM use and the caller→server attribution over `range`. Answers "why is the GPU pinned, and which service is calling the model server?".

• get_history

  Charted time-series the dashboard graphs over `range`: timestamps + aligned arrays for GPU util/VRAM/power/temp and host CPU/RAM/load/temp. Use for trends.

• get_host

  Full System / Network / Security inventory for a single host. `name` is the host's registered name, or "local" for the hub itself.

• get_installed_models

  Installed-models registry (#219): every AI model available on the hub — grouped by provider (ollama, vllm, llama.cpp, LM Studio, ComfyUI, …) — not just what's currently loaded. Ollama entries carry on-disk size/quant/param detail; other providers carry name/loaded/vram. Answers "what can I run, and where?" without SSHing in to run `ollama list` or poke a server's API by hand.

• get_memory

  RAM breakdown behind the memory treemap: per-service peak/avg/present RAM over `range`, the current RAM per process right now, kernel (non-reclaimable) memory, and totals. Answers "what is eating RAM on this hub?".

Signals

Stars

225

Forks

36

Open issues

37

Contributors

21

Last commit

Oct 24, 2026 (4 days ago)

Last release

Sep 23, 2026 (1 month ago)

Last package publish

Oct 24, 2026 (4 days ago)

From GitHub (fetched Oct 24, 2026) and the package registry.

Details

Registry name

io.github.SikamikanikoBG/homelab-monitor

Version

0.14.2

Auth

No auth

Packages

oci docker.io/sikamikaniko123/homelab-monitor:0.14.2

License

MIT

Repository

github.com/SikamikanikoBG/homelab-monitor

Website

sikamikanikobg.github.io/homelab-monitor/mcp/

First seen

Oct 24, 2026

Last checked

Oct 24, 2026

Source

Official MCP Registrygithub-graphql