MCP-Server¶

Der MCP-Server stellt eine universelle Schnittstelle für alle KI-Systeme bereit, um auf die Heimnetz-Infrastruktur zuzugreifen — per SSH auf Proxmox und alle Container, sowie zum Lesen und Schreiben des Wikis. Kompatibel mit jedem MCP-fähigen Client (Claude, GPT, Gemini, lokale Agenten, …) und erreichbar von jedem Gerät.

Seit v3.0 (Juli 2026) läuft der Server ohne root-Rechte. Seit v4.0 (August 2026) ist der MCP modular aufgebaut, besitzt eine zentrale Tool-Registry, MCP-Resources für Arbeitsregeln, eine grafische Tool-Verwaltung und ein 7-Tage-Audit-Log. Siehe Sicherheitsmodell. Verbindliche Arbeitsregeln für alle KIs: MCP-Arbeitsregeln.

Architektur¶

KI (Claude, GPT, andere MCP-Clients)         Admin (nur Mensch)
    │                                             │
    │  HTTPS + Cloudflare Access JWT              │
    ▼                                             ▼
mcp.diebrocks.com  (Cloudflare Tunnel)   mcp.diebrocks.com/admin/*
    │                                             │
    ▼                                             ▼
MCP-Server :3000 (User mcp)              Admin-UI :3001 (root)
Container 108 (10.10.10.33)            Container 108
    │
    ├── SSH als mcp-agent → Proxmox (10.10.10.10)  [nur Wrapper mcp-pct/mcp-maintenance]
    ├── SSH als mcp-agent → ebusd-Lüftung (10.10.10.32)   [voller sudo]
    ├── SSH als mcp-agent → ebusd-Heizung (10.10.10.31)   [voller sudo]
    ├── SSH als mcp-agent → cloudflared (10.10.10.30)     [voller sudo]
    ├── SSH als mcp-agent → mcp-server selbst (10.10.10.33) [kein sudo]
    ├── SSH als ssh       → Home Assistant (10.10.10.20)
    ├── SSH als mcp       → MikroTik (10.10.10.1)       [eingeschränkter User mcp]
    └── Git → GitHub (HerrBausW/smarthome-wiki)

Benutzerkonvention¶

Das Zugriffsschema ist bewusst getrennt:

Rolle	Benutzer	Einsatz
MCP-Prozess	`mcp`	lokal auf CT 108, ohne sudo
Linux-Remotezugriff	`mcp-agent`	Proxmox sowie CT 102/106/107/108
MikroTik	`mcp`	eingeschränkter RouterOS-Benutzer
Home Assistant	`ssh`	SSH-Add-on-Benutzer

Sicherheitsmodell¶

Grundidee: Stufenmodell mit unantastbarem Gate¶

shell_execute ist der Schalter zwischen zwei Betriebsarten:

Aus: Nur die normalen, selbst whitelisteten MCP-Tools funktionieren.
An: Die KI darf tiefgreifende Änderungen machen — auf den Arbeits-Containern (cloudflared, ebusd-heizung, ebusd-lueftung) sogar mit vollem root (via sudo). Ausgenommen bleibt immer das Gate selbst: das shell_execute-Flag, tool-config.json und der Server-Code (index.js = die Tool-Definitionen).

Die Gate-Garantie ist technisch erzwungen, nicht nur per Software-Filter, weil die KI auf genau den zwei Hosts kein root bekommen kann, von denen aus das Gate erreichbar wäre:

Container 108 (mcp-server): Hier liegt das Gate. Der Server läuft als unprivilegierter User mcp (uid 999, kein sudo, NoNewPrivileges=yes); /opt/mcp-shell/ und /opt/mcp-admin/ sind root-owned.
Proxmox-Host (Hypervisor): Von hier aus könnte man per pct enter 108 das Gate von außen umschreiben. Deshalb bekommt mcp-agent dort keinen vollen sudo, sondern nur die zwei Whitelist-Wrapper.

Rechte-Matrix¶

Host	SSH-User	shell_execute AN	shell_execute AUS
cloudflared (102)	`mcp-agent`	voller root (`sudo ALL`)	nur normale Tools
ebusd-heizung (106)	`mcp-agent`	voller root (`sudo ALL`)	nur normale Tools
ebusd-lueftung (107)	`mcp-agent`	voller root (`sudo ALL`)	nur normale Tools
proxmox (Hypervisor)	`mcp-agent`	nur `mcp-pct` + `mcp-maintenance`	nur normale Tools
mcp-server (108)	`mcp-agent` / lokal `mcp`	alles als `mcp`, nie root	nur normale Tools
home-assistant	`ssh`	SSH-Addon-User	nur normale Tools
MikroTik (Router)	`mcp`	RouterOS CLI (eingeschränkt)	RouterOS CLI (eingeschränkt)

Der mcp-agent-Key ist mit no-port-forwarding,no-agent-forwarding,no-X11-forwarding eingeschränkt. Der alte root-Key des MCP-Servers wurde von allen Hosts entfernt und auf 108 gelöscht.

Wer kann was ändern?¶

Aktion	Wer
`shell_execute` an/aus	nur Mensch über Admin-UI (oder root auf 108)
`tool-config.json` (write-Allowlist, Tools deaktivieren)	nur Mensch über Admin-UI (oder root auf 108)
Neue MCP-Tools definieren (`index.js`)	nur root auf 108 (`pct enter 108`)
Alles auf 102/106/107	KI bei aktivem shell_execute

Weitere Schutzschichten¶

write_file mit Pfad-Allowlist pro Host aus tool-config.json, plus Hard-Deny im Code (.ssh, authorized_keys, sudoers, shadow, known_hosts, id_ed25519, /etc/systemd, *.service, ..). Übertragung Base64-kodiert.
disabled_tools in tool-config.json deaktiviert beliebige Tools zur Laufzeit. Deaktivierte Tools werden bei neuen MCP-Anfragen nicht mehr registriert/angeboten und zusätzlich beim Aufruf serverseitig blockiert.
Audit-Log: Jeder Tool-Aufruf wird mit Identität, Parametern, Ergebnis/Fehler und Laufzeit unter /var/log/mcp-audit/YYYY-MM-DD.jsonl protokolliert. Sensible Felder werden maskiert; Dateien älter als 7 Tage werden automatisch gelöscht.
Die Tools shell_enable/shell_disable wurden entfernt; unbekannte Hosts werden abgelehnt (kein Fallback auf root@<ip>).

sudo-Wrapper (Proxmox)¶

/usr/local/bin/mcp-pct: validiert alle Argumente per Regex und erlaubt ausschließlich:

mcp-pct list | status | start | stop | restart <id>
mcp-pct exec <id> systemctl <status|start|stop|restart> <service>
mcp-pct exec <id> journalctl-unit <service> [zeilen]
mcp-pct exec <id> journalctl-clear

/usr/local/bin/mcp-maintenance (auf allen Debian-Hosts, auf 102/106/107 seit v3.1 redundant): check (apt update + list --upgradable), upgrade (apt upgrade -y), cleanup (autoremove + autoclean).

tool-config.json (Stand Juli 2026)¶

{
  "disabled_tools": [],
  "write_allow": {
    "ebusd-heizung": ["/etc/ebusd/", "/tmp/"],
    "ebusd-lueftung": ["/etc/ebusd/", "/tmp/"],
    "home-assistant": ["/config/", "/tmp/"],
    "mcp-server": ["/tmp/"],
    "proxmox": [],
    "cloudflared": []
  }
}

Admin-UI¶

URL: https://mcp.diebrocks.com/admin (Cloudflare-Ingress leitet /admin-Pfade auf Port 3001, alles andere auf Port 3000)
Prozess: /opt/mcp-admin/server.js, systemd-Unit mcp-admin, läuft als root
Zugriff: nur mit Cloudflare-Access-JWT einer erlaubten E-Mail (enrico.brock@gmail.com); Service-Tokens → 403
Funktionen: shell_execute an/aus, alle MCP-Tools gruppiert anzeigen und einzeln aktivieren/deaktivieren, Risikostufen anzeigen, 24h/3d/7d-Audit ansehen, tool-config.json erweitert bearbeiten, mcp-shell-Service neu starten (Notfall-Recovery)

Container¶

Eigenschaft	Wert
Container-ID	108
Hostname	mcp-server
IP	10.10.10.33 (statisch)
OS	Debian 13
Ports	3000 (MCP, User mcp) / 3001 (Admin-UI, root)
Autostart	ja (Proxmox + systemd: `mcp-shell`, `mcp-admin`)

Bekannte Hosts¶

Hostname	IP	SSH-User	Container-ID	Beschreibung
`proxmox`	10.10.10.10	mcp-agent	—	Proxmox Hypervisor
`cloudflared`	10.10.10.30	mcp-agent	102	Cloudflare Tunnel
`ebusd-heizung`	10.10.10.31	mcp-agent	106	ebusd Heizung (Vaillant)
`ebusd-lueftung`	10.10.10.32	mcp-agent	107	ebusd Lüftung (Vaillant Recovair)
`mcp-server`	10.10.10.33	mcp-agent	108	MCP-Server
`home-assistant`	10.10.10.20	ssh	—	Home Assistant
`ebusd-stick-heizung`	10.10.30.14	—	—	ebusd C6 Stick Heizung (kein SSH, nur Web)
`ebusd-stick-lueftung`	10.10.30.15	—	—	ebusd C6 Stick Lüftung (kein SSH, nur Web)
`mikrotik`	10.10.10.1	mcp	—	MikroTik hAP ax2 (Produktivrouter)

SSH-Vertrauensdaten (`known_hosts`)¶

Die Host-Schlüssel für die per SSH erreichbaren Infrastrukturziele liegen unter:

/home/mcp/.ssh/known_hosts

Stand 10.08.2026 sind Einträge für alle produktiv verwendeten SSH-Ziele vorhanden:

Ziel	IP	Status
MikroTik	`10.10.10.1`	Host-Key vorhanden; Zugriff erfolgt über den eingeschränkten RouterOS-User `mcp`
Proxmox	`10.10.10.10`	SSH-Verbindung als `mcp-agent` erfolgreich geprüft
Home Assistant	`10.10.10.20`	SSH-Verbindung als `ssh` erfolgreich geprüft
cloudflared	`10.10.10.30`	SSH-Verbindung als `mcp-agent` erfolgreich geprüft
ebusd-Heizung	`10.10.10.31`	SSH-Verbindung als `mcp-agent` erfolgreich geprüft
ebusd-Lüftung	`10.10.10.32`	SSH-Verbindung als `mcp-agent` erfolgreich geprüft
MCP-Server	`10.10.10.33`	SSH-Verbindung als `mcp-agent` erfolgreich geprüft

Bei MikroTik ist ein generischer Linux-Test wie echo ok kein geeigneter Funktionstest, weil der RouterOS-Benutzer absichtlich nur eingeschränkte Befehlsrechte besitzt. Ein Fehler wie not enough permission bei einem nicht freigegebenen Testbefehl bedeutet daher nicht, dass die SSH-Verbindung oder Host-Key-Prüfung fehlschlägt.

Wenn sich ein Host-Key nach Neuinstallation oder Systemänderung ändert, schlägt SSH mit Host key verification failed fehl. In diesem Fall den alten Eintrag gezielt entfernen und den aktuellen Schlüssel neu einlesen; nicht pauschal die Host-Key-Prüfung deaktivieren.

Verfügbare Tools¶

Tool-Typen¶

Symbol	Typ	MCP-Annotation	Bedeutung
🔒	Schreibgeschützt	`readOnlyHint: true`	Liest nur — keine Änderungen möglich
✏️	Schreibend	—	Ändert Konfiguration oder Dateien
⚠️	Destruktiv	`destructiveHint: true`	Kann Daten löschen oder Dienste unterbrechen
🔴	Kritisch	`destructiveHint: true` + `title`	Voller Shell- oder Router-Zugriff, oder Dienst-Neustart

Anzeige in KI-Clients

Claude und ChatGPT werten diese Annotationen aus: 🔒-Tools werden als „schreibgeschützt" hervorgehoben, 🔴-Tools erhalten einen Warn-Titel.

Namenskonvention¶

Alle Tools folgen zwei einheitlichen Mustern:

Allgemeine Tools: verb_noun — z.B. get_logs, read_file, install_updates
Subsystem-Tools: prefix_verb oder prefix_get_noun — z.B. wiki_read, mikrotik_get_interfaces

Lese-Tools beginnen immer mit get_, list_, read_, check_ oder enden auf _status.

Infrastruktur¶

Tool	Typ	Parameter	Beschreibung
`get_infrastructure`	🔒	—	Alle Hosts, IPs, Container-IDs, Zweck

Shell¶

shell_execute nur über Admin-UI aktivierbar

shell_execute ist standardmäßig deaktiviert. Aktivierung/Deaktivierung ausschließlich über die Admin-UI (https://mcp.diebrocks.com/admin). Bei aktivem Flag hat die KI vollen root auf den Arbeits-Containern 102/106/107 — das Gate selbst (Flag, tool-config.json, index.js) bleibt immer unerreichbar.

Tool	Typ	Parameter	Beschreibung
`get_shell_status`	🔒	—	Zeigt ob shell_execute aktiv oder deaktiviert ist
`shell_execute`	🔴	`command`	Shell-Befehl auf dem MCP-Server (als User mcp) — nur wenn aktiviert

Proxmox Container¶

Alle Container-Tools laufen über den sudo-Wrapper mcp-pct auf dem Proxmox-Host.

Tool	Typ	Parameter	Beschreibung
`list_containers`	🔒	—	Alle Container mit Status
`get_container_status`	🔒	`container_id`	Status eines Containers
`start_container`	✏️	`container_id`	Container starten
`stop_container`	⚠️	`container_id`	Container stoppen
`restart_container`	🔴	`container_id`	Container neu starten

Services¶

Tool	Typ	Parameter	Beschreibung
`get_service_status`	🔒	`container_id`, `service`	Service Status prüfen
`restart_service`	🔴	`container_id`, `service`	Service neu starten (Whitelist-validiert)

Logs¶

Tool	Typ	Parameter	Beschreibung
`get_logs`	🔒	`container_id`, `service`, `lines`	Logs abrufen (Standard: 50 Zeilen)
`get_audit_logs`	🔒	`lines` (optional)	Audit-Log des MCP-Servers abrufen
`clear_logs`	⚠️	`container_id`	Journal des Containers rotieren/leeren

Dateien¶

Tool	Typ	Parameter	Beschreibung
`read_file`	🔒	`host`, `path`	Datei lesen (nur was mcp-agent lesen darf)
`write_file`	⚠️	`host`, `path`, `content`	Datei schreiben — nur Pfade aus der Allowlist in `tool-config.json`

Netzwerk & System¶

Tool	Typ	Parameter	Beschreibung
`check_reachability`	🔒	`host`	Erreichbarkeit per Ping prüfen
`get_system_info`	🔒	`host`	CPU, RAM, Disk, Uptime
`check_updates`	🔒	`host`	Verfügbare Updates prüfen
`install_updates`	⚠️	`host`	Updates installieren (apt upgrade)
`clean_system`	⚠️	`host`	Aufräumen (apt autoremove + autoclean)

Wiki¶

Tool	Typ	Parameter	Beschreibung
`wiki_list`	🔒	`folder` (optional)	Alle Markdown-Dateien im Wiki auflisten
`wiki_read`	🔒	`file`	Wiki-Seite lesen (Pfad relativ zu `docs/`)
`wiki_write`	✏️	`file`, `content`, `commit_message`	Wiki-Seite schreiben und direkt auf GitHub pushen
`wiki_delete`	⚠️	`file`, `commit_message`	Wiki-Seite löschen (`git rm`) und auf GitHub pushen — nur `.md`-Dateien in `docs/`
`wiki_sync`	⚠️	—	Wiki-Repo vom GitHub aktualisieren (git pull)

MikroTik¶

Direkter Zugriff auf den MikroTik hAP ax2 (Router, 10.10.10.1) per SSH als eingeschränkter User mcp. Der User darf lesen und konfigurieren, aber nicht rebooten, zurücksetzen oder Benutzer verwalten.

Tool	Typ	Parameter	Beschreibung
`mikrotik_get_dhcp_leases`	🔒	—	Aktive DHCP-Leases anzeigen
`mikrotik_get_interfaces`	🔒	—	Interfaces und Bridge-Ports anzeigen
`mikrotik_get_firewall`	🔒	—	Firewall-Regeln (input + forward) anzeigen
`mikrotik_execute`	🔴	`command`	Beliebiger RouterOS-CLI-Befehl (z.B. `/ip/address/print`)

Cloudflare¶

Application: DieBrocks MCP (mcp.diebrocks.com)
AUD-Tag: dc3471d55adac87c1f1714c6195298f6949fc3b47b76c84b75c698a82f828718
Team Domain: https://diebrocks.cloudflareaccess.com
Richtlinie: MCP Konnektor (erlaubt enrico.brock@gmail.com + Service Token claude-mcp)
Tunnel-Ingress (Container 102, /root/.cloudflared/config.yml): mcp.diebrocks.com + Pfad ^/admin → 10.10.10.33:3001, sonst → 10.10.10.33:3000

SSH-Keys¶

Key	Datei	Verwendung
mcp-remote	`/home/mcp/.ssh/id_ed25519`	SSH als `mcp-agent` auf alle Hosts (bzw. `ssh` auf HA); SSH als `mcp` auf MikroTik
Wiki-Key	`/home/mcp/.ssh/id_ed25519_wiki`	GitHub Deploy Key für `smarthome-wiki` (write), Alias `github-wiki` in `/home/mcp/.ssh/config`

Die alten root-Keys des MCP-Servers wurden im Juli 2026 von allen Hosts entfernt und auf 108 gelöscht.

Connector einrichten¶

Der Server funktioniert mit jedem MCP-fähigen Client über Streamable HTTP. Authentifizierung immer über die zwei Cloudflare-Access-Header.

URL: https://mcp.diebrocks.com/mcp
Header: CF-Access-Client-Id + CF-Access-Client-Secret (aus Cloudflare Zero Trust → Dienstanmeldeinformationen → claude-mcp)

Beispiel: claude.ai (Browser/App)¶

claude.ai → Einstellungen → Connectors → Hinzufügen
URL und benutzerdefinierte Header wie oben

Beispiel: Claude Code (Desktop App)¶

In settings.json:

{
  "mcpServers": {
    "diebrocks-mcp": {
      "type": "http",
      "url": "https://mcp.diebrocks.com/mcp",
      "headers": {
        "CF-Access-Client-Id": "<client-id>",
        "CF-Access-Client-Secret": "<client-secret>"
      }
    }
  }
}

Service Token sicher aufbewahren

Das Client-Secret wird von Cloudflare nur einmal angezeigt. Für weitere KI-Systeme ggf. eigene Service-Tokens in Cloudflare Zero Trust anlegen (bessere Nachvollziehbarkeit im Audit-Log).

Dateien¶

/opt/mcp-shell/               # produktiver MCP-Code, root-owned; mcp darf nur lesen
├── index.js                  # schlanker MCP-v4-Bootstrap
├── tool-registry.js          # zentraler Katalog: Name, Beschreibung, Kategorie, Risiko
├── tools/                    # Tool-Module (Infrastruktur, Proxmox, System, Dateien, Wiki, MikroTik)
├── lib/core.js               # SSH, Security, Tool-Registrierung, Audit
├── rules/                    # globale und subsystembezogene MCP-Regeln/Resources
├── tool-config.json          # root-owned: disabled_tools + write_allow
├── shell_execute.enabled     # root-owned Flagge: existiert = shell_execute aktiv
├── package.json
└── node_modules/

/opt/mcp-admin/               # root-owned
├── server.js                 # Admin-UI v4 (root, Port 3001)
├── package.json
└── node_modules -> /opt/mcp-shell/node_modules

/opt/wiki/                    # Geklontes smarthome-wiki Repo (Owner: mcp)
/home/mcp/.ssh/               # SSH-Keys des Servers
/var/log/mcp-audit/           # Tagesdateien YYYY-MM-DD.jsonl, automatische 7-Tage-Retention

Systemd Services¶

# /etc/systemd/system/mcp-shell.service
[Unit]
Description=MCP Shell Server (laeuft als unprivilegierter User mcp)
After=network.target

[Service]
Type=simple
User=mcp
Group=mcp
WorkingDirectory=/opt/mcp-shell
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=3
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/mcp-admin.service
[Unit]
Description=MCP Admin UI (root, Port 3001)
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/mcp-admin
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Wartung¶

# Status prüfen (auf Proxmox)
pct exec 108 -- systemctl status mcp-shell mcp-admin

# Neustart
pct exec 108 -- systemctl restart mcp-shell

# Logs
pct exec 108 -- journalctl -u mcp-shell -n 50

# In Container einloggen (einziger Weg, Tools in index.js zu ändern)
pct enter 108

# shell_execute-Flag manuell (als root im Container; normalerweise Admin-UI nutzen)
touch /opt/mcp-shell/shell_execute.enabled   # aktivieren
rm /opt/mcp-shell/shell_execute.enabled      # deaktivieren

MCP v4 ändern (neue Tools, Bugfixes)¶

Produktiver MCP-Code bleibt root-geschützt

/opt/mcp-shell/ und /opt/mcp-admin/ sind root-owned. Der MCP-Prozess läuft als User mcp ohne sudo und kann seine produktiven Tools, Regeln oder Admin-Oberfläche nicht selbst überschreiben. Das ist das zentrale Sicherheits-Gate.

Modularer Aufbau¶

Neue Tools werden im passenden Modul unter /opt/mcp-shell/tools/ implementiert.
Name, Beschreibung, Kategorie und Risikostufe werden zentral in /opt/mcp-shell/tool-registry.js gepflegt.
Gemeinsame Sicherheits-, SSH- und Audit-Funktionen liegen in /opt/mcp-shell/lib/core.js.
Verbindliche KI-Regeln liegen unter /opt/mcp-shell/rules/ und werden zusätzlich als MCP Resources bereitgestellt.
Änderungen an der Admin-Oberfläche erfolgen in /opt/mcp-admin/server.js.

Deployment-Verfahren¶

Die KI darf Änderungen mit aktiviertem shell_execute in einem beschreibbaren Staging-Verzeichnis vorbereiten, Syntax und gerenderten Browser-Code prüfen und ein Deployment-Script erstellen. Die produktive Installation muss anschließend vom Menschen als root auf Proxmox bzw. in Container 108 gestartet werden.

Vor jeder produktiven Aktualisierung:

aktuelle produktive Dateien sichern;
JavaScript-Syntax aller Module prüfen;
bei Admin-UI-Änderungen auch das aus dem Template tatsächlich gerenderte Browser-JavaScript prüfen;
Dateien root-owned installieren;
mcp-shell bzw. mcp-admin neu starten;
Service-Status und mindestens einen echten MCP-Aufruf verifizieren;
Audit-Log prüfen und Wiki aktualisieren.

Rollback¶

Vor Deployments werden root-geschützte Backups unter /root/ im Container angelegt. Bei einem fehlgeschlagenen MCP-Start bleibt Proxmox der unabhängige Notzugang:

pct enter 108
systemctl status mcp-shell mcp-admin
journalctl -u mcp-shell -n 100

Danach kann die letzte Sicherung aus /root/ zurückgespielt und der jeweilige Dienst neu gestartet werden.

Nach dem Deployment¶

Tool-Verwaltung in der Admin-UI prüfen.
Einen harmlosen MCP-Aufruf ausführen und dessen Eintrag im Audit kontrollieren.
shell_execute über die Admin-UI deaktivieren, falls es nur für die Wartung aktiviert war.
Staging-Dateien bereinigen; mindestens ein bewusst gewähltes Rollback-Backup kann bis zur nächsten stabilen Wartung erhalten bleiben.

Wartungshistorie¶

Datum	Maßnahme
10.08.2026	MCP v4 produktiv: modularer Tool-Aufbau, zentrale Tool-Registry mit 29 Tools, ausgelagerte MCP-Regeln/Resources, Admin-UI mit Tool-Schaltern und Risikostufen, erweitertes Audit-Logging mit 7-Tage-Retention; Admin-JavaScript-Hotfix nach Deployment verifiziert
10.08.2026	SSH-`known_hosts` vervollständigt und geprüft: Einträge für MikroTik (`10.10.10.1`), Proxmox (`10.10.10.10`), Home Assistant (`10.10.10.20`), cloudflared (`10.10.10.30`), ebusd-Heizung (`10.10.10.31`), ebusd-Lüftung (`10.10.10.32`) und MCP-Server (`10.10.10.33`) vorhanden; Linux-SSH-Ziele erfolgreich verbunden
06.08.2026	`wiki_delete`-Tool hinzugefügt (git rm + commit + push, nur .md in docs/); Deploy-Verfahren für index.js dokumentiert
31.07.2026	Postfix deinstalliert (Port 25 geschlossen, war Debian-Default)
31.07.2026	Journal-Limit gesetzt: max. 50 MB, 4-Wochen-Retention (`/etc/systemd/journald.conf.d/size-limit.conf`)
31.07.2026	Locale `en_US.UTF-8` generiert und als System-Default gesetzt (`dpkg-reconfigure locales`)
31.07.2026	Proxmox-Autostart aktiviert (CT 108 startet jetzt automatisch nach Reboot)

MCP-Server¶

Architektur¶

Benutzerkonvention¶

Sicherheitsmodell¶

Grundidee: Stufenmodell mit unantastbarem Gate¶

Rechte-Matrix¶

Wer kann was ändern?¶

Weitere Schutzschichten¶

sudo-Wrapper (Proxmox)¶

tool-config.json (Stand Juli 2026)¶

Admin-UI¶

Container¶

Bekannte Hosts¶

SSH-Vertrauensdaten (known_hosts)¶

Verfügbare Tools¶

Tool-Typen¶

Namenskonvention¶

Infrastruktur¶

Shell¶

Proxmox Container¶

Services¶

Logs¶

Dateien¶

Netzwerk & System¶

Wiki¶

MikroTik¶

Cloudflare¶

SSH-Keys¶

Connector einrichten¶

Beispiel: claude.ai (Browser/App)¶

Beispiel: Claude Code (Desktop App)¶

Dateien¶

Systemd Services¶

Wartung¶

MCP v4 ändern (neue Tools, Bugfixes)¶

Modularer Aufbau¶

Deployment-Verfahren¶

Rollback¶

Nach dem Deployment¶

Wartungshistorie¶

SSH-Vertrauensdaten (`known_hosts`)¶