Legacy MCP: La scommessa
Cosa può realizzare un vecchio sistemista con 20 euro in un mese?
English version available here → [EN]
Venerdì 13 marzo 2026, una data che sembra anonima, se vista dal lato scaramantico in alcune culture c’è chi crede che porti sfortuna, ma per me ha un significato particolare: mi è venuta un’idea e la voglio realizzare.
In realtà i semi di quell’idea arrivano da un percorso iniziato qualche tempo prima.
Il primo risale al 6 maggio 2025: European Identity Conference a Berlino, seconda sessione della giornata, tra i top trend previsti per il 2025 c’è l’esplosione degli MCP Server.
Guardo in faccia il mio collega e ci facciamo la stessa domanda: cosa diavolo è un MCP Server? Dobbiamo assolutamente approfondire!
Passano mesi e come da perfetta profezia gli MCP Server iniziano a spuntare come funghi.
Il secondo seme risale al 25 febbraio 2026: è da un po’ che sento l’esigenza di scrivere su “roba legacy”, parlo con un collega e finalmente trovo la “casa” giusta per il mio progetto. Immediatamente decido di aprire questo blog su Substack e nel giro di una settimana pubblico il primo articolo. È il 1° marzo 2026.
L’essere su questa piattaforma mi ha però dato la possibilità di leggere cose molto interessanti negli altri blog della piattaforma. Molto spesso sono argomenti distanti tecnicamente dal mio lavoro, ma che risuonano bene con il mio modo di vedere le cose.
Ma torniamo al 13 marzo 2026, leggo un post dove si parla dell’evoluzione di Claude.ai. Parla di quanto i suoi nuovi modelli siano potenti e di un esperimento di Vibe Coding estremo.
Ecco, quello è l’ultimo seme…
L’idea inizia a germogliarmi in testa, arrivato a sera inizio la mia prima chiacchierata con l’app Claude, breve botta e risposta ed ecco che trova la sua forma:
E se volessi scrivere una interfaccia MCP per Active Directory?
Ci dormo sopra (si fa per dire) e mi sveglio con un disegno piuttosto chiaro in testa.
Dopo colazione inizio a bombardare l’AI facendo un “dump” della mia memoria e lei tiene il ritmo. Arriviamo ad una prima bozza, ma c’è un bel sole e l’erba alta mi chiama, è tempo di uscire.
Taglio, medito, scarico, taglio, medito, scarico e così via…
Pomeriggio secondo round con l’AI, altro dump massivo ed arriviamo ad un disegno molto chiaro, decido che è ora da fare una scommessa:
può un vecchio sistemista, con un passato di programmazione che si è fermato a Visual Basic 6, ma che conosce bene i sistemi, creare da zero un progetto per un MCP Server open source?
È in quel momento che investo 20 euro per accedere a Claude Code e ufficialmente nasce il progetto Legacy MCP.
Domenica 15 marzo 2026, mi sveglio e mi dedico alla mia passione per la Formula 1, e faccio bene.
Una giovane promessa dell’automobilismo italiano, a soli 19 anni, parte dalla pole position, domina la gara e ottiene la sua prima vittoria, centrando una scommessa fatta dalla Mercedes quando aveva solo 11 anni. È Andrea Kimi Antonelli.
Sono euforico e penso che sarà una grande giornata, mi metto quindi all’opera per impostare i lavori e dopo pranzo “accendo le macchine”, tempo un paio d’ore ed ho il primo prototipo funzionante.
Quando vedo che posso interrogare i dati esattamente come mi ero immaginato mi casca la mascella e rimango letteralmente a bocca aperta, pensando: sì questa è una scommessa che va portata a termine!
Questo articolo non nasce per spiegare una tecnologia, ma per raccontare un percorso.
È il racconto di cosa succede quando un’idea legacy incontra strumenti nuovi, e qualcuno decide di provarci davvero, mettendo in contatto i due mondi.
Perché serviva farlo
Se avete letto i miei articoli precedenti (Capitolo 1, Capitolo 2 ) saprete già il mio punto di vista, per i nuovi lettori lo riassumo brevemente: nonostante la spinta al cloud, le tecnologie legacy continuano a sopravvivere. Solo che, col tempo, stanno iniziando a diventare misteriose e quindi serve un modo per tramandarle.
Ogni progetto che viene avviato dal mio team parte sempre dallo stesso punto: dobbiamo fare un assessment e produrre un documento.
E nella stragrande maggioranza dei casi, il cuore dell’assessment è sempre lui: Active Directory.
Per anni ci si è affidati alla fedele PowerShell con soluzioni scripting più o meno standard, ma con un punto fermo: l’uso dell’ottimo ADDS_Inventory_V3.ps1 del mitico Carl Webster.
Il problema è che lo sviluppo e la manutenzione di questi script stanno diventando sempre più onerosi, mentre fuori il mondo surfa veloce sull’onda dell’AI.
Non volevo buttare via quel patrimonio: volevo renderlo interrogabile, modulare e riutilizzabile.
E allora mi sono fatto una domanda semplice: perché non provare a mettere in contatto questi due mondi?
La chiave di volta l’ho trovata nel protocollo MCP. Molto spesso viene descritto come “la porta USB per l’AI”: uno standard aperto che permette di “connettere” i sistemi di AI a moduli esterni di qualsiasi tipo.
Per chi vuole approfondire rimando alla documentazione ufficiale: What is the Model Context Protocol (MCP)? - Model Context Protocol
Da qui nasce l’idea di realizzare un Server MCP che faccia da ponte tra il mondo Active Directory e i sistemi di AI: Legacy MCP.
In pratica: un modo standard per interrogare AD usando strumenti AI, spostando il focus dal come al cosa.
Come anticipato, durante i primi due giorni ho avuto intense sessioni con Claude Chat: ho definito principi e linee guida che mi hanno permesso di vedere risultati tangibili in meno di 48 ore.
Tra questi c’è la distinzione netta tra progetto open core ed enterprise: va bene che sono “solo” 20 euro, ma fare le cose bene richiede tempo, quindi serve anche darsi un limite.
La scelta è stata piuttosto semplice, naturale e coerente:
se il progetto prende spunto dal grande lavoro di Carl Webster, allora l’open core deve coprire tutto quello che per anni ha coperto lo script ADDS_Inventory_V3.ps1.
È un modo per restituire alla community una parte di quello che ho ricevuto, ma portandolo al passo con le tecnologie attuali.
Su queste basi, verrà poi portato avanti uno strato enterprise che richiede sforzi ed investimenti differenti, e che coprirà funzionalità più avanzate e sofisticate:
· open core = inventario e interrogazioni fondamentali
· enterprise = analisi avanzate / report / integrazioni
Cosa può fare per te
Legacy MCP nasce per un obiettivo semplice: rendere interrogabile Active Directory, permettendo correlazioni incrociate tra i dati e spostando il focus sul che cosa mi serve capire.
A seconda del contesto (offline, rete locale, internet) lo stesso approccio si declina in profili di deployment diversi, pensati per bilanciare praticità e sicurezza: A / B-core / B-enterprise / C.
In tutti i profili, comunque, il flusso logico è lo stesso: porto i dati in un workspace, poi interrogo. Cambia solo dove girano server e dati, e quanto è governato l’accesso.
Tutti i dettagli operativi li trovate nel repository, adesso concentriamoci su casi d’uso reali.
Tre scenari, tre livelli di fiducia: file, LAN, internet.
Caso d’uso #1 - Assessment remoto offline + report
Profilo: A (open core)
Scenario: Un consulente deve analizzare un ambiente AD remoto, a volte può avere accesso diretto in VPN o sessione condivisa, in altri casi la raccolta è demandata al cliente.
Approccio: Invece di generare un report statico, raccoglie i dati in modo standard con un collector PowerShell, o chiede al cliente di farlo. L’output è un JSON con dati e metadati di sessione.
Analisi: Sul proprio PC configura Legacy MCP in locale, “monta” il JSON nel workspace e interroga l’ambiente tramite Claude Desktop.
Risultato. Ottiene un’analisi strutturata sulle aree di proprio interesse e, quando serve, un output documentale (nel progetto sono già stati prodotti alcuni report DOCX su ambienti reali).
Un esempio reale, questa è la risposta che LegacyMCP permette di ottenere in pochi secondi a una domanda concreta sull’ambiente:
Questo è il profilo più semplice: massimizza portabilità e ripetibilità, e minimizza la dipendenza dall’ambiente del cliente. Permette anche analisi incrociate tra ambienti correlati.
Caso d’uso #2 - Dialogo interattivo live + confronto storico (snapshot)
Profilo: B-core o B-enterprise (in base al livello di sicurezza richiesto).
Scenario: Team IT o consulenti vogliono interrogare l’ambiente “dal vivo”, con la comodità del dialogo in chat, senza esportare continuamente file.
Approccio: Legacy MCP viene eseguito in rete locale su un server dell’ambiente Active Directory (member server). Le comunicazioni sono cifrate e il modello di autenticazione è coerente con il profilo scelto.
Interazione: I client (Claude Desktop) si collegano al server MCP tramite modulo bridge (mcp-remote) in LAN. Nel progetto questo pattern è già stato testato end‑to‑end su Profilo B-core con HTTPS e autenticazione basata su token/chiavi protette.
Valore extra: Quando serve “memoria”, si generano snapshot nel tempo. Questo permette di montare snapshot e live insieme chiedendo la domanda più semplice (e più potente): cosa è cambiato?
Il profilo B, lavorando su dato live, ha requisiti di sicurezza più stringenti (account dedicato, cifratura end-to-end e accesso governato). I dettagli sono nel repository.
Nota importante: Legacy MCP espone funzioni di sola lettura (read-only).
Caso d’uso #3 - Portale di analisi esposto su Internet
Profilo: C (solo enterprise)
Scenario: si vuole rendere l’assessment scalabile e fruibile come servizio: più team, più clienti, accesso da ovunque, ma senza necessità di accessi live all’infrastruttura.
Approccio: Si lavora solo su dati offline. È possibile effettuare upload dei JSON, gestione dei workspace via web. L’analisi avviene tramite agenti che consumano MCP su endpoint pubblici.
Sicurezza: Questo profilo richiede un layer di protezione su rete pubblica: API gateway (es. APIM) + WAF. L’autenticazione è demandata ad un Identity Provider (tipicamente Entra ID) con MFA all’accesso ed RBAC sui dati caricati.
Perché ha senso: È il passo che trasforma un tool in una piattaforma, con lo stesso modello logico (profili, workspace, snapshot/offline), ma con governance e accesso enterprise.
Al momento questo è solamente un caso d’uso teorico, ma con specifiche già ben definite. Va bene il Vibe Coding, ma da solo in un mese di lavoro non sarei riuscito ad arrivare a tanto.
Roma non è stata fatta in un giorno
Pensare al concetto di Vibe Coding mi fa andare in modalità Legacy Things e nelle orecchie mi inizia a suonare un famoso pezzo uscito nel 2000: Rome Wasn’t Built in a Day dei Morcheeba.
È la colonna sonora perfetta per descrivere il percorso che ho affrontato durante il mese della scommessa.
Ovunque leggo articoli e proclami che suonano più o meno così:
come ho creato qualcosa da zero in 35 minuti grazie all’AI e il Vibe Coding.
Dal mio punto di osservazione, quella è una mezza verità, fatta per catturare l’attenzione. Forse ci mettiamo anche la mia scelta di non usare un motore di coding estremo (Claude Sonnet 4.6), ma vi voglio raccontare come ho realmente vissuto l’esperienza.
Punto primo
È sicuramente vero che una volta fornite le istruzioni il motore di coding ci mette pochi minuti a creare il risultato, ma la vera questione è: quanto tempo ho impiegato tra ideare, ragionare in autonomia e conversare con una chat di AI prima di arrivare alle istruzioni?
Se prendiamo come esempio l’idea iniziale ve l’ho già svelato: due giorni.
E ne sono serviti altri 28 per arrivare ad un risultato che mi facesse dire “ok lo possiamo pubblicare”.
Chiaro, dipende molto da “che cosa” voglio realizzare, lo sforzo è proporzionale all’ambizione del progetto.
Punto secondo
Oltre al tempo, serve avere una direzione chiara e polso fermo, altrimenti l’AI ti porta a spasso dove vuole lei.
Per fare un esempio, durante una lunga e faticosa sessione di debug sull’autenticazione live verso i Domain Controller, l’AI ha provato di farmi semplificare l’approccio scalando dal protocollo Kerberos ad NTLM.
A quel punto sono rimasto fermo rimarcando i miei principi di sicurezza e alla fine siamo arrivati a farlo funzionare come volevo.
Adesso nella memoria di progetto leggo: NTLM must never be used — deprecated; Kerberos only for Live Mode
Punto terzo
Non sempre l’AI da sola ti trova la soluzione migliore, a volte perde di vista il dettaglio chiave.
Portando un altro esempio, durante la configurazione dell’accesso sicuro lato client MCP, mi sono scontrato su come gestire al meglio la chiave API senza esporla. La soluzione trovata è stata quella di passare da un PowerShell e usare le DPAPI.
Tutto bello fino a che l’avvio del PowerShell da Claude Chat moriva miseramente con uno strano errore. Dopo un’altra intensa sessione di troubleshooting è stata mia l’intuizione di avviare il codice PowerShell dentro un caro vecchio file BAT, risolvendo immediatamente.
La sessione rimane nella memoria di progetto come “BAT is King” in perfetto stile Legacy Things, dove una tecnologia “antica” risolve un problema di AI.
Timeline
Di seguito vi lascio una timeline di cosa sono riuscito ad ottenere ed in che tempi, se la guardo sono veramente impressionato, ma non è una roba da 35 minuti:
Roma non è stata fatta in un giorno e nemmeno questo progetto. L’AI accelera tutto, ma senza una guida non farebbe altro che schiantarsi.
Ti permette di raggiungere vette altissime, ma una volta in cima ci dobbiamo chiedere: chi ha veramente scalato la montagna?
Chi ha veramente scalato la montagna?
Quando l’idea ha preso forma e mi sono deciso a dedicare tempo sul serio al progetto, mi sono sentito un po’ come se avessi avuto una montagna da scalare. Questo all’inizio un po’ mi ha spaventato, ma non avevo nulla da perdere e sapevo di poter contare su strumenti veramente all’avanguardia in ambito AI.
Sono partito con una base standard sull’uso di AI chat, ma non sapevo nulla di coding con AI, un vero “newbie”.
Strada facendo mi sono però messo in gioco, mi sono documentato ed ho capito che per fare un buon lavoro, serve una buona dote di soft skill: idee chiare, forti capacità comunicative, tenacia e tanto metodo.
Volutamente mi sono spinto a scrivere codice in un linguaggio che non conosco (python) perché quello che mi interessava non era il codice, ma il risultato ottenuto.
Dopo le prime settimane mi sono reso conto che il limite tecnico principale era quello del “credito”, le sessioni di lavoro andavano distribuite ed ottimizzate, nel corso della giornata e della settimana. Senza una gestione oculata si rimaneva presto “senza benzina” sul più bello.
Per tenere bassi i consumi nel credito di Claude il punto chiave è stato quello di ridurre il contesto: usare la stessa chat per giorni saturava la finestra di contesto e consumava tantissimi token.
Col tempo ho quindi messo insieme un flusso di lavoro strutturato in tre livelli che vi voglio raccontare.
Strumenti utilizzati: Claude.ai (piano pro, per un mese) a cui ho aggiunto Perplexity.ai, un piano pro che con una promozione avevo in uso per un anno.
Ho poi creato un progetto dentro Claude ed uno spazio dentro Perplexity. In entrambe ho allegato un file status.md con il riepilogo totale. Il file viene allegato anche nella root di progetto ad uso di Claude Code.
Per il codice ho usato VS Code con l’estensione di Claude Code.
Il flusso in ingresso è stato di questo tipo:
1. Prima bozza di ragionamento su Perplexity con motore Sonnet 4.6 per coerenza con i passaggi successivi
2. La bozza di istruzioni di Perplexity viene passata a Claude Chat per una valutazione e successivo affinamento. Claude Chat apre una nuova sessione dallo status.md e genera le istruzioni per Claude Code.
3. Claude Code esegue e genera un riepilogo
4. Claude Chat valuta il riepilogo e quando arrivati ad un risultato stabile chiude la sessione aggiornando il file status.md
5. Il file aggiornato status.md viene allegato ovunque come nuovo riferimento univoco.
Questo il flusso in uscita:
1. Il riepilogo di Claude Chat viene passato a Perplexity come feedback
2. Vengono avviate le sessioni di test e debug
3. Quando necessaria qualche variazione si torna al flusso di ingresso verso Claude Chat
Come sono arrivato a questo metodo? Leggendo in giro e dialogando con l’AI. Serve molta autocritica e pensiero laterale, chiedendosi ogni tanto: posso migliorare qualcosa?
Ma torniamo alla domanda iniziale: chi ha veramente scalato la montagna?
Per rispondere uso una metafora: mi sento come se avessi scalato una montagna molto alta, arrivando dove non avrei pensato, ma ero dotato di un sofisticato esoscheletro (l’AI) che ha amplificato enormemente le mie capacità.
Ma l’esoscheletro da solo non va da nessuna parte. E più diventi bravo a sfruttarne le potenzialità, più procedi spedito.
Cosa ho osservato ed imparato
Lunedì 13 aprile, il repository è ufficialmente pubblico, la scommessa è conclusa ed è ora di tracciare un bilancio.
Sono riuscito nel mio obiettivo? Decisamente sì!
Ce l’avrei fatta senza l’aiuto dell’AI? Decisamente no!
Il primo aspetto chiave da evidenziare è la relazione di collaborazione che si instaura tra te e l’AI.
C’è di mezzo un processo di continuo apprendimento reciproco. Più tu impari ad utilizzare lo strumento nel contesto del progetto, più lui impara a conoscerti, con in mezzo una parola chiave: comunicazione.
L’AI applicata alla programmazione ha ribaltato un paradigma: non sei più tu a dover imparare un linguaggio, è lo strumento che ha imparato il tuo.
Questo sposta il focus dal come ottenere un risultato al cosa voglio realmente ottenere.
Perché questo meccanismo funzioni serve però che chi avvia la comunicazione (tu) sia capace di farlo nella maniera migliore.
Ho capito infatti che l’AI è un potente amplificatore: se escono idee confuse il risultato sarà estremamente confuso, se sono precise il risultato sarà estremamente preciso.
Il secondo aspetto fondamentale su cui ragionare è la conoscenza della materia: senza sapere esattamente come funzionano le cose si rischiano risultati divergenti dall’obiettivo senza rendersene conto, vedi il caso NTLM citato in precedenza.
Questo significa che con l’AI non ci si può adagiare “tanto ci pensa lei”, anzi bisogna concentrarsi nell’imparare il più possibile come funzionano le cose. Questo valorizzerà il ruolo di architetto che sarà sempre più importante.
Il terzo aspetto su cui ragionare è che i sistemi di AI sono alla fine degli strumenti, e come tali vanno impiegati al meglio.
Per questo motivo bisogna approcciarli con metodo, provando, sbagliando e mettendosi in discussione per migliorarlo. Ma attenzione, non esiste un solo metodo giusto, ognuno troverà quello migliore per sé stesso e per lo specifico contesto nel quale si trova ad operare.
Il mio metodo ha funzionato perché non era già scritto in partenza, ma l’ho costruito passo-passo chiedendomi: cosa posso fare meglio?
Chiudo i ragionamenti con un motto che mi porto dietro da 25 anni e che oggi trovo più attuale che mai:
i sistemi informatici non fanno quello che vuoi, ma quello che gli dici di fare.
Spero che questo racconto ti abbia appassionato almeno quanto ha appassionato me realizzarlo. La storia però non finisce qui. Quando leggerai questo articolo il codice si sarà già evoluto, e non posso andare avanti da solo.
Là fuori c’è un repository che aspetta di essere provato. Mettilo alla prova e fammi sapere come ti sei trovato.