Christoph Emsenhuber
b4419e2d3d
- Netzwerk-Schema-Hinweis: 10.40.41.x ist tot, alle Hosts auf neues Schema.
- MikroMCP/pve-mcp/komodo-mcp/portainer-mcp: .41.x → .20.x korrigiert.
- omada-mcp + omada-controller: ⛔ RETIRED 2026-08-27 (Omada-Stack raus).
- 'Claude Code' → 'opencode' (Tool-Wechsel, s. Inventur-Handoff).
- 'später'/'Router-Cutover' Phrasen an aktuelle Realität angepasst.
4.5 KiB
MCP-Inventar — BF (Single Source of Truth gegen "1000 MCP-Leichen")
Regel: Jeder MCP-Server, der für BF läuft, steht hier — sonst existiert er nicht. Kein lokaler Ad-hoc-
npx-Wildwuchs auf Laptops. Zentral = Docker auf einem Host, FQDN-adressiert. Wer einen MCP abschaltet, streicht die Zeile (oder setzt Statusretiredmit Datum).Richtungsentscheid (User, 2026-07-11): MCP-Dienste gehören grundsätzlich auf zentrale Serverdienste, nicht auf den Client. Die aktuell Client-lokal laufenden (MikroMCP stdio, shelly-mcp
:3030) sind bewusste pragmatische Interims ("Hauptsache es funktioniert") und werden zu einem späteren Zeitpunkt zentral zusammengezogen (ein Host, Container, FQDN) — Teil der Control-Plane-Konsolidierung (vgl. TP11 / Komodo-Migration).
Aktive / geplante MCPs
Netzwerk-Schema ab 2026-08-27:
10.40.<vlan>.<oktet>— altes10.40.41.xist tot. Hosts in dieser Tabelle sind auf das neue Schema zu prüfen.
| MCP | Zweck / Geräte | Host | Transport / Endpoint | Image | Config | Status |
|---|---|---|---|---|---|---|
| MikroMCP (AliKarami) | MikroTik hAP ax² ap1/ap2 (RouterOS 7) — WLAN/CAPsMAN, Router-Cutover | jetzt: lokal (dieser Mac) / Ziel: Mac mini 10.40.20.167 Docker |
jetzt stdio (npx mikromcp serve) / Ziel HTTP :3000 |
ghcr.io/alikarami/mikromcp:latest (HTTP) bzw. npm mikromcp (stdio) |
mcp/mikromcp/ + opencode/Claude-Code user-config |
🟢 live (stdio), doctor 12/12, in opencode ✓Connected |
| shelly-mcp (eigenbau, FastMCP) | ~26 Shellys Gen3/4 — VLAN1→VLAN30-Migration (TP17) + Verwaltung | jetzt: lokal (dieser Mac) :3030 / Ziel: zentral (Container) |
StreamableHTTP http://127.0.0.1:3030/mcp (+ Status /, Health /health) |
eigenbau mcp/shelly/server.py |
mcp/shelly/ ✓ (.env PSK) |
🟢 live (Interim, Client-lokal). Tools: discover/get/set_sta[guarded]/verify/reservation_plan |
| pve-mcp (samik081) | Proxmox VE API (Host .100) |
DS923 (10.40.20.10), macvlan-IP 10.40.20.173 |
SSE http://10.40.20.173:3000/sse |
ghcr.io/samik081/mcp-pve:latest |
— (Stack via Portainer) | 🟢 live, in opencode eingetragen |
| komodo-mcp (samik081) | Docker-Management 5 Hosts via Komodo Core (ersetzt Portainer) | DS923 (10.40.20.10), macvlan-IP 10.40.20.176 |
SSE http://10.40.20.176:3000/sse |
ghcr.io/samik081/mcp-komodo:latest |
mcp/komodo/ ✓ (.env.example → .env nach Phase 1) |
🟡 geplant — Migration: mcp/komodo/MIGRATION.md |
| Docker-Überblick via Portainer CE 2.40.0 | 10.40.20.126:9443 |
— | portainer/portainer-mcp |
mcp/portainer/ (Token .env ✓) |
⏳ retired nach Komodo-Migration — Token aufheben bis Phase 4 | |
| TP-Link Omada Controller | — | — | jmtvms/tplink-omada-mcp:latest |
mcp/omada/ ✓ |
⛔ RETIRED 2026-08-27 — Omada-Stack raus, wir fahren auf MikroTik. Container stoppen, Image optional behalten. | |
| Omada Software Controller | 10.40.20.175:8043 |
— | mbentley/omada-controller:6.2 |
omada/docker-compose.yml |
⛔ RETIRED 2026-08-27 | |
| ALLNET ALL-SG8316M Core-Switch | — | — | — | — | ⛔ bewusst NICHT (Telnet/1-VTY/15-min-Lock auf Core = zu fragil). User-Entscheid: erst beschriebener Weg, sonst MikroTik-Core-Tausch. |
Legende: 🟢 live · 🟡 staged (Config da, nicht deployed) · 🔴 blockiert · ⛔ bewusst nicht gemacht
Anti-Sprawl-Regeln
- Zentral statt lokal: MCPs laufen als Container auf einem festen Host, nicht als
npxpro Laptop. - Eine Zeile pro MCP in dieser Tabelle. Kein Eintrag → abschalten.
- Config im Git (
mcp/<name>/), Secrets nur in.env(gitignored). - FQDN statt IP, sobald eingerichtet (DNS-Rewrite) → Endpoint-Spalte updaten.
- Review-Datum: mind. halbjährlich diese Tabelle gegen tatsächlich laufende Container prüfen
(
docker psauf den Hosts).
ALLNET — warum kein MCP
ALL-SG8316M (Core) nach FW-2.2.1-Flash: Web-UI tot, nur Telnet-CLI, kein SSH/REST/SNMP-Write,
nur 1 VTY-Line, ~15 min Busy-Lock bei Stale-Sessions. Ein MCP darüber wäre auf dem Core-Switch
(an dem alles hängt) fragil und lockout-gefährlich. → Management bleibt bei der bestehenden
Telnet-CLI-Toolchain (switch/cli/). Strategische Option: Core-Switch (Methusalem, Bj. 2015)
gegen einen Omada-Switch tauschen → fällt unter denselben Omada-Controller/omada-mcp.
Das ist Hardware-Ausgabe + Core-Cutover → User-Entscheidung (offen).