[Plan] MCP-Skalierung fuer Cline - Richtung ~20 MCPs sauber managen #104

New issue

Open

opened 2026-06-13 21:43:37 +00:00 by orbitalo · 0 comments

orbitalo commented

2026-06-13 21:43:37 +00:00

Owner

Ziel

Clines MCP-Set waechst (aktuell 6: openmemory, forgejo, savetv, homelab_docs aktiv; cloudflare, playwright deaktiviert). Mittelfristig Richtung ~20 MCPs. Das ist machbar - der Knackpunkt ist nicht die Anzahl, sondern das Management der Tool-Surface pro Request.

Kernproblem

Nicht die Zahl der MCPs kostet, sondern wie viele Tool-Definitionen pro Request ins Modell wandern. 20 MCPs x 5-15 Tools = 150+ Tools x Schema = mehrere tausend Tokens in JEDEM Aufruf an DeepSeek (Cloud, gemetert). Das ist der zu managende Hebel.

Geplante naechste MCPs (Backends existieren alle)

MCP	Zweck	Backend	Tier
monitoring_mcp	Prometheus/Loki/Grafana-Abfragen	Loki@CT110, Grafana12+InfluxDB@CT143	1 (zuerst)
proxmox_mcp	CT/VM lesen, Status, begrenzt steuern	Fleet (pve-*)	1 (READ-FIRST)
services_mcp	systemctl/logs erlaubte Dienste	diverse	2 (redundant zu SSH)
seafile_mcp	Dateien/Backups/Medien	Seafile-Server	3 (nische)
jellyfin_mcp	Medienbestand/Jobs	100.77.105.3	3 (nische)

Management-Strategie (aufsteigend nach Reife)

Selektives Aktivieren pro Aufgabe - Cline kann MCPs einzeln an/aus. Einfach, manuell.
MCP-Gateway/Router (der skalierbare Weg) - ein Aggregator-MCP (z.B. mcphub/Proxy) buendelt N Backends und zeigt dem Modell nur eine kuratierte, dynamische Tool-Auswahl. 20 Backends, aber nie 150 Tools gleichzeitig im Kontext. Frueh bauen (bei MCP ~8-10), nicht erst bei 15.
Namensraum-Disziplin - klare Zustaendigkeiten gegen Ueberlappung (services vs proxmox vs SSH), sonst raet das Modell.
Policy: read-first Default, destruktiv gegated - bei Schreibrechten ueber Cloud-Agent einmal zentral, nicht pro MCP.
Registry + Nutzungs-Review - Doku pro MCP (Zweck/Endpoint/Auth) in CT 999 oder hier; periodisch pruefen welche real genutzt werden, tote raus.

Wichtigster Vorbehalt

proxmox_mcp Steuerung ueber ein Cloud-Modell (DeepSeek), das den ganzen Fleet sieht, ist die groesste Schadensflaeche. Start: nur lesen + Status, jede steuernde Aktion mit Bestaetigung.

Naechste Schritte

monitoring_mcp (read-only) bauen - groesster Diagnose-Mehrwert.
proxmox_mcp read-first bauen.
Entscheidung MCP-Gateway-Tool evaluieren (mcphub o.ae.) bevor MCP-Zahl >10.
MCP-Registry-Struktur festlegen (wo, welches Format).
services_mcp/seafile_mcp/jellyfin_mcp nur bei konkretem wiederkehrendem Bedarf.

## Ziel Clines MCP-Set waechst (aktuell 6: openmemory, forgejo, savetv, homelab_docs aktiv; cloudflare, playwright deaktiviert). Mittelfristig Richtung ~20 MCPs. Das ist machbar - der Knackpunkt ist nicht die Anzahl, sondern das **Management der Tool-Surface pro Request**. ## Kernproblem Nicht die Zahl der MCPs kostet, sondern wie viele **Tool-Definitionen pro Request** ins Modell wandern. 20 MCPs x 5-15 Tools = 150+ Tools x Schema = mehrere tausend Tokens in JEDEM Aufruf an DeepSeek (Cloud, gemetert). Das ist der zu managende Hebel. ## Geplante naechste MCPs (Backends existieren alle) | MCP | Zweck | Backend | Tier | |---|---|---|---| | monitoring_mcp | Prometheus/Loki/Grafana-Abfragen | Loki@CT110, Grafana12+InfluxDB@CT143 | 1 (zuerst) | | proxmox_mcp | CT/VM lesen, Status, begrenzt steuern | Fleet (pve-*) | 1 (READ-FIRST) | | services_mcp | systemctl/logs erlaubte Dienste | diverse | 2 (redundant zu SSH) | | seafile_mcp | Dateien/Backups/Medien | Seafile-Server | 3 (nische) | | jellyfin_mcp | Medienbestand/Jobs | 100.77.105.3 | 3 (nische) | ## Management-Strategie (aufsteigend nach Reife) 1. **Selektives Aktivieren pro Aufgabe** - Cline kann MCPs einzeln an/aus. Einfach, manuell. 2. **MCP-Gateway/Router (der skalierbare Weg)** - ein Aggregator-MCP (z.B. mcphub/Proxy) buendelt N Backends und zeigt dem Modell nur eine kuratierte, dynamische Tool-Auswahl. 20 Backends, aber nie 150 Tools gleichzeitig im Kontext. **Frueh bauen (bei MCP ~8-10), nicht erst bei 15.** 3. **Namensraum-Disziplin** - klare Zustaendigkeiten gegen Ueberlappung (services vs proxmox vs SSH), sonst raet das Modell. 4. **Policy: read-first Default, destruktiv gegated** - bei Schreibrechten ueber Cloud-Agent einmal zentral, nicht pro MCP. 5. **Registry + Nutzungs-Review** - Doku pro MCP (Zweck/Endpoint/Auth) in CT 999 oder hier; periodisch pruefen welche real genutzt werden, tote raus. ## Wichtigster Vorbehalt **proxmox_mcp Steuerung** ueber ein Cloud-Modell (DeepSeek), das den ganzen Fleet sieht, ist die groesste Schadensflaeche. Start: nur lesen + Status, jede steuernde Aktion mit Bestaetigung. ## Naechste Schritte - [ ] monitoring_mcp (read-only) bauen - groesster Diagnose-Mehrwert. - [ ] proxmox_mcp read-first bauen. - [ ] Entscheidung MCP-Gateway-Tool evaluieren (mcphub o.ae.) bevor MCP-Zahl >10. - [ ] MCP-Registry-Struktur festlegen (wo, welches Format). - [ ] services_mcp/seafile_mcp/jellyfin_mcp nur bei konkretem wiederkehrendem Bedarf.