Zum Inhalt

Homelab MCP2 – Funktionsparität zu MCP1

Stand 05.10.2026: Version 0.6.31. MCP2 (homelab-mcp, CT 109) ersetzt den alten MCP (CT 108, mcp.DieBrocks.home). Alle Funktionen der Paritätsmatrix sind live geprüft; MCP1 wird für keine bekannte produktive Funktion mehr benötigt.

Toolkatalog und Client-Cache

Der Server liefert den Katalog bei jedem Aufruf neu (zustandslos, keine Sessions). listChanged-Benachrichtigungen sind deshalb nicht möglich. Clients wie ChatGPT oder Claude halten ihre Toolliste im Cache. Folge: alte Tools (z. B. dev_*) bleiben sichtbar, neue (z. B. wiki_delete) fehlen, bis der Connector aktualisiert oder neu verbunden wird.

Prüfung ohne Client:

  • system_status zeigt tools.toolCount, tools.catalogRevision und tools.unavailablePlugins.
  • Lokal gegen 127.0.0.1:3000/mcp (JSON-RPC tools/list) sieht man die tatsächlich ausgelieferten Tools.

Stand: 54 Tools, Revision e2826a8de593, keine nicht verfügbaren Plugins, dev_* nicht im Katalog (developer-tools deaktiviert).

Hinweis: Der MCP-Dienst liest ssh.json nur beim Start. Nach einem Update kann ein Neustart zeitgleich zum Schreiben der Datei einen veralteten Stand laden (Symptom: weniger Tools, z. B. 48 statt 54). Abhilfe: Admin-UI → Übersicht → „MCP neu starten“.

Update-Ablauf und Wartezeiten

Ablauf: Tag pushen → Pipeline (Tests, .deb bauen, APT-Repo veröffentlichen, rund 1 Minute) → release.json und APT-Index liegen auf raw.githubusercontent.com → Admin-UI „Jetzt aktualisieren“ → Update-Dienst (rund 15 Sekunden) → Seite lädt neu.

  • GitHub-Cache: raw.githubusercontent.com cached den main-Zweig bis zu 5 Minuten (Cache-Control: max-age=300), auch mit Cache-Buster-Parameter. Eine neue Version erscheint deshalb oft erst 4–6 Minuten nach dem Push. release.json und APT-Index haben eigene Cache-Zeiten und können kurz auseinanderlaufen (die Oberfläche zeigt dann z. B. „installiert 0.6.31, veröffentlicht 0.6.30“).
  • Update-Dienst: Seit 0.6.31 liest self-update.sh die in release.json angekündigte Version und wiederholt apt-get update alle 15 Sekunden (höchstens 30 Mal), bis der Index sie anbietet. Davor lief der Dienst bei veraltetem Index erfolgreich durch, installierte aber nichts.
  • Seiten-Reload: Die Oberfläche steht immer auf /admin/#ansicht. location.replace() auf dieselbe URL lädt nicht neu; bis 0.6.29 blieb der Banner deshalb nach jedem Update stehen. Seit 0.6.30 lädt location.reload().
  • Möglicher nächster Schritt: APT-Repo nicht über raw.githubusercontent.com, sondern über einen Dienst ohne Cache-Verzögerung (z. B. Cloudflare Pages) ausliefern.

Änderungen

Version Änderung
0.6.24 ha_get_skill_guide sendet nur noch file. check_reachability mit TCP-Fallback (Dienst läuft ohne CAP_NET_RAW). system_status mit Katalog-Diagnose.
0.6.25 Admin-UI: Update-Fortschritt als fixiertes Banner oben, Endzustand mit Schließen-Button.
0.6.26 Container-Neustart repariert (pct kennt kein restart, Wrapper setzt auf pct reboot um). Längere, begrenzte SSH-Timeouts. Einrichtungsseite mit vier gleichartigen Karten.
0.6.27 Update-Anzeige repariert: Ein oneshot-Dienst meldet activating, das galt fälschlich als „fertig“.
0.6.28 Einrichtung überschreibt bestehende Policy und Einzel-Freigaben nicht mehr (Proxmox, SSH-Ziele, MikroTik, Wiki, Home Assistant).
0.6.29 Update-Wartephase mit Zeitlimits und Watchdog; deutscher Hinweis statt „Failed to fetch“.
0.6.30 Seite lädt nach dem Update tatsächlich neu (location.reload() statt location.replace() auf dieselbe URL).
0.6.31 Update-Dienst wartet auf einen aktuellen APT-Index; die Oberfläche erklärt die Wartezeit.

Wrapper auf dem Proxmox-Host

/usr/local/bin/mcp-pct muss die Umsetzung restart → pct reboot enthalten. Der Befehl steht unter Admin-UI → Einrichtung → Proxmox und wird als root auf dem Proxmox-Host ausgeführt. Am 05.10.2026 neu installiert und bestätigt.

SSH-Timeouts

Standard 10 s. Built-in-Tools dürfen einen begrenzten Timeout (1 s bis 300 s) anfordern: *_install_updates 300 s, *_clean_system 120 s, Container Start/Stop/Neustart 120 s, proxmox_restart_service 60 s.

Paritätsmatrix

MCP1 MCP2 Getestet
check_reachability check_reachability ja (TCP-Fallback)
get_infrastructure, get_shell_status, shell_execute, get_audit_logs gleichnamig ja
list_containers, get_container_status proxmox_list_containers, proxmox_get_container_status ja
start_container, stop_container, restart_container proxmox_* ja (CT 110)
get_service_status, get_logs proxmox_get_service_status, proxmox_get_logs (mit containerId) ja
restart_service proxmox_restart_service ja (cron in CT 110)
clear_logs proxmox_clear_logs ja (CT 107, Journal danach leer, ebusd läuft)
get_system_info, check_updates proxmox_*, cloudflared_*, ebusd_heizung_*, ebusd_lueftung_* ja
install_updates ebusd_heizung_*, ebusd_lueftung_* ja (CT 106 und 107)
clean_system gleichnamig je System ja (ebusd-heizung)
read_file, write_file <system>_read_file, <system>_write_file proxmox_read_file ja, Schreiben nach /tmp auf ebusd-heizung ja
mikrotik_list_devices, _get_interfaces, _get_firewall, _get_dhcp_leases gleichnamig ja (AP1–3)
mikrotik_execute mikrotik_execute mit target ja (Read AP1–3, Write AP1)
ha_search_tools, ha_call_read_tool, ha_call_write_tool, ha_get_skill_guide gleichnamig ja
ha_call_delete_tool gleichnamig ja (Test-Helfer angelegt und gelöscht)
wiki_list, wiki_read, wiki_write, wiki_sync, wiki_delete gleichnamig ja

Sicherheitsverhalten (geprüft)

  • mikrotik_execute akzeptiert nur konfigurierte Targets; unbekannte Namen und fehlendes target bei mehreren Geräten werden abgewiesen, rohe IPs scheitern am Schema.
  • wiki_delete ist Opt-in: Das Setup vergibt nur read/write, Löschen wird in der Admin-UI unter Tools → Wiki pro Tool freigeschaltet.
  • Jeder Aufruf erscheint im Audit-Log (attempt und success/error).

Restpunkte

  • Kein Shell-Zugriff mehr auf den Home-Assistant-Host (nur die eingeschränkten HA-Datei-Tools der Bridge).
  • CT 108 ist kein Ziel mehr; das entfällt mit der Abschaltung von MCP1.
  • Der vollständige automatische Update-Ablauf (Banner, Reload) mit den Korrekturen ab 0.6.30 ist erst mit dem nächsten Update im Echtbetrieb sichtbar; der Reload selbst ist im Browser bestätigt.
  • Firewall AP1: Die Regeln für den MCP-Server decken 10.10.10.33 (MCP1) und 10.10.10.34 ab. Nach der Abschaltung von MCP1 lassen sie sich auf .34 verengen.

Verwandt: Release-Verwaltung, Home-Assistant-Bridge