Guida operativa MCL MCP 2026

Documentazione unica e progressiva per utilizzare il connettore MCL da ChatGPT, verificare ciò che è stato eseguito e riutilizzare procedure che hanno realmente funzionato.

1. Regole operative obbligatorie

1. Individuare il server dall'inventario canonico, non per intuizione.
2. Preferire uno strumento MCP dedicato quando disponibile.
3. Eseguire preflight e verificare capacità, permessi e identità del server.
4. Per modifiche produttive: backup, modifica circoscritta, test, eventuale rollback.
5. Non disabilitare verifiche SSH o controlli di sicurezza per far passare una richiesta.
6. Riprovare errori di connessione transitori in modo idempotente; non ripetere mutazioni già riuscite.
7. Registrare comando o strumento utilizzato, risultato e verifica finale.

Riferimenti interni: docs/MCL_CONNECTOR_RETRY_POLICY.md e docs/MCL_SERVER_ADOPTION.md.

2. Strumenti MCP: fatti e limiti

Non esistono ancora, nel catalogo disponibile in questa sessione, strumenti dedicati universali per creare siti, configurare Cloudflare o gestire Nginx. Non presentarli come già implementati.

3. Verificare un server

Il registro storico è organizzazione_capability_matrix.json. La diagnostica eseguibile esistente è mcl_fleet_diagnostics.py. Per il controllo simultaneo dei server principali:

python3 -B mcl_mcp_live_canary.py

Ultimo risultato salvato in mcl_mcp_live_canary_latest.json. Questo test legge identità e trasporto, non modifica le VPS e non certifica la scrittura.

4. Creare un nuovo sottodominio

Esempio: guida-mcp.mclmedia.eu. Procedura di riferimento da adattare solo dopo verifica dell'host:

1. Identificare la VPS, il suo IP pubblico e la piattaforma web dal registro.
2. Verificare se il DNS Cloudflare è già presente, altrimenti creare il record autorizzato.
3. Creare cartella applicazione e configurazione Nginx dedicata senza toccare altri siti.
4. Eseguire nginx -t prima di ricaricare.
5. Ottenere o installare un certificato valido e controllarne il rinnovo.
6. Provare HTTP, HTTPS, hostname, contenuti e status code dall'esterno.
7. Registrare il sito in Organizzazione e documentare eventuali errori.

La procedura è un runbook, non uno strumento MCP di provisioning già certificato.

5. Errori noti e soluzioni verificate

Blocco preventivo di un comando Bash

Sintomo: «non siamo riusciti a determinare lo stato di sicurezza della richiesta».

Diagnosi: la richiesta può essere rifiutata prima del server. Il 16 ottobre un comando di sola lettura è stato bloccato, mentre la lettura del medesimo file via read_file è riuscita.

Soluzione verificata: usare la funzione MCP specifica quando supporta l'operazione. Non aggirare i controlli di sicurezza.

Strumento presente nel codice ma non esposto

Sintomo: funzione presente in /opt/mcl-mcp/server.py ma assente dal catalogo disponibile in ChatGPT.

Stato: rilevato il 16 ottobre; riallineamento del catalogo ancora da verificare.

Errore host key SSH

Sintomo: Host key verification failed.

Correzione: verificare impronta digitale e identità con fonte indipendente attendibile; non disabilitare StrictHostKeyChecking.

QA applicativo

Gli errori BLOCKED_PED_QA e calendar_date_requires_review appartengono ai validatori applicativi: non attribuirli automaticamente al connettore.

6. Scheda standard per ogni intervento

Richiesta:
Server e dominio:
Tool MCP utilizzato:
Preflight / capacità:
Backup / rollback:
Modifica eseguita:
Esito tecnico:
Verifica applicativa / HTTP:
Errore incontrato:
Soluzione effettivamente verificata:
Stato finale: VERIFICATO | PARZIALE | BLOCCATO
Data / responsabile:

Quando emerge un nuovo errore, aggiungere qui una scheda con causa accertata e soluzione realmente testata. Le ipotesi vanno indicate come tali.

7. Registro delle modifiche