Ecosistema MCP italiano 2026: chi costruisce cosa

Risposta diretta: in Italia l'ecosistema MCP nel 2026 è piccolo, vivo e quasi invisibile. Non è dominato da aziende: i progetti più maturi vengono da comunità di sviluppatori indipendenti e, in modo inatteso, da istituzioni pubbliche. Il problema di questo ecosistema non è la qualità tecnica — è la scopribilità: ottimi server esistono, funzionano e nessuno li trova. Questa è la ricognizione, progetto per progetto, di cosa c'è.

TL;DR

• I progetti più maturi del catalogo italiano non nascono da aziende ma da comunità di builder indipendenti.
• Il più solido espone il bilancio della Camera dei Deputati voce per voce, con una doppia licenza (open più commerciale) che è di per sé un caso di studio sulla sostenibilità del civic tech.
• Esistono due approcci opposti alla legal-AI open source italiana: applicazione desktop locale contro servizio web. Vale la pena capire perché.
• Ci sono istituzioni pubbliche nel catalogo — è il dato più sottovalutato, e lo approfondisco a parte.
• Due persone hanno mappato indipendentemente gli stessi dati parlamentari, con scelte diverse. Nessuna delle due sapeva dell'altra.
• Il collo di bottiglia dell'ecosistema è la scopribilità, non la tecnica: il costo di un progetto che non si trova è lo stesso di un progetto che non esiste.

Come ho fatto questa ricognizione

Non per scrivere un articolo: per lavoro. Stavo valutando quali progetti esistenti potessero servire a OpenLegis invece di riscrivere cose già fatte da altri. Sono partito dal catalogo pubblico e collaborativo dei server MCP italiani e li ho provati, non solo letti.

La ricognizione che segue è dello stato a settembre 2026. Su repository pubblici, un'informazione del genere invecchia in fretta: prima di adottare qualcosa, verifica l'ultimo commit.

I progetti che reggono

Il bilancio della Camera, voce per voce

Il progetto più maturo del catalogo espone il bilancio della Camera dei Deputati in modo interrogabile, voce per voce. L'ho provato con dati reali: funziona.

Ma la parte interessante non è tecnica, è il modello di licenza: doppia licenza, open source copyleft forte più licenza commerciale. Cioè: chiunque può usarlo e studiarlo, chi vuole integrarlo in un prodotto chiuso paga.

Questo merita attenzione perché risolve, almeno sulla carta, il problema che uccide la maggior parte dei progetti civici italiani: sono gratis, quindi nessuno li finanzia, quindi dopo due anni si fermano. La doppia licenza è uno dei pochi modelli che permette a un progetto civico di avere un ricavo senza tradire l'apertura. Che funzioni davvero è un'altra questione — ma è la domanda giusta da porsi.

Una comunità, non un singolo sviluppatore

Dietro quel progetto non c'è una persona: c'è una comunità di builder italiani che produce più progetti seri. È un dettaglio che cambia la lettura dell'ecosistema. La narrazione abituale del civic tech italiano è quella dell'eroe solitario che molla dopo tre anni; qui c'è una struttura che distribuisce il carico, ed è il motivo per cui i progetti sopravvivono.

Due modi opposti di fare legal-AI open source

Nel catalogo c'è un assistente legale che lavora sulle fonti normative italiane — Normattiva, standard Akoma Ntoso ed ELI — ancora agli inizi, ma con una scelta architetturale radicalmente diversa dalla mia.

Dimensione	Applicazione locale	Servizio web (OpenLegis)
Dove girano i dati	Sul computer dell'utente	Su un'infrastruttura centrale
Privacy	Massima: niente esce dalla macchina	Richiede fiducia nel gestore
Aggiornamento del corpus	A carico dell'utente	Centralizzato e continuo
Costo per l'utente	Zero dopo l'installazione	Modello a servizio
Capacità di calcolo	Limitata dall'hardware locale	Scalabile
Grafo di relazioni fra norme	Difficile da costruire e tenere	È esattamente il punto di forza

Non c'è una scelta giusta: ci sono due prodotti diversi. Il locale vince su privacy e costo marginale; il centralizzato vince quando il valore sta nell'incrocio fra fonti diverse, che è il cuore del ragionamento sui knowledge graph. Vale la pena dirlo con rispetto: chi ha scelto la strada locale ha risolto un problema che io ho aggirato, e viceversa.

Due mappature indipendenti degli stessi dati

Il dettaglio che mi ha colpito di più: due persone hanno mappato indipendentemente gli stessi endpoint SPARQL di Camera e Senato, con approcci diversi, senza sapere l'una dell'altra.

Da un lato è spreco: due volte lo stesso lavoro ingrato. Dall'altro è successo qualcosa di più interessante — leggendo i problemi documentati dall'altro progetto (una lista lunga di comportamenti anomali del motore dietro quei dati), ho trovato due bug reali nel mio codice:

1. Un confronto fra date fatto su stringhe non normalizzate: filtravo con un formato AAAA-MM-GG contro valori memorizzati senza trattini. Il confronto avveniva, ma lessicograficamente, cioè sbagliato in silenzio.
2. Un errore di sintassi nella query: un doppio annidamento di operatori di ordinamento che il motore rifiutava con un codice d'errore criptico.

Entrambi verificati dal vivo contro l'endpoint reale, prima e dopo la correzione. È collaborazione open source senza che ci sia stata collaborazione: nessuno ha aperto una issue, nessuno si è scritto. È bastato che l'altro avesse documentato bene i propri inciampi.

Il progetto meno rilevante, con il README migliore

Nel catalogo c'è un server MCP tecnicamente marginale il cui README è, di gran lunga, il migliore del gruppo: spiega cosa fa, per chi, con quali limiti, con esempi che si possono copiare. Merita una citazione proprio per questo. In un ecosistema dove il problema principale è farsi trovare e farsi capire, scrivere bene è un vantaggio competitivo, non un dettaglio di cortesia.

Il vero problema: nessuno sa che esistono

Qui devo mettere in mezzo me stesso, perché sono l'esempio peggiore.

Ho un secondo server MCP pubblicato su PyPI da mesi. Funzionante. Con 24 strumenti implementati. Il suo README ne documentava due, perché il repository collegato era rimasto privato e nessuno aveva mai aggiornato la descrizione pubblica.

Era installabile da chiunque nel mondo con un comando, e invisibile a tutti. Non l'ho scoperto per un'analisi di mercato: l'ho scoperto per caso, mentre facevo questa ricognizione, trovando il mio stesso pacchetto in una lista.

La lezione non è «fai marketing». È più asciutta: un prodotto che esiste e non si trova, per il mondo, non esiste — e il costo che hai pagato per costruirlo è identico. Nell'ecosistema MCP italiano questo è il collo di bottiglia dominante: non mancano le competenze, manca la superficie su cui incontrarsi.

Se vuoi contribuire, tre cose che servono più di un nuovo server

1. Documenta i tuoi inciampi. La lista dei comportamenti strani di una fonte pubblica vale, per chi arriva dopo, quanto il codice. A me ha fatto trovare due bug.
2. Aggiungi il tuo progetto al catalogo pubblico. Sembra ovvio, non lo è: la maggior parte dei progetti seri che esistono non ci sono.
3. Prima di scrivere un server nuovo, controlla se qualcuno ha già mappato quella fonte. Se sì, contribuisci lì. Due mappature indipendenti dello stesso endpoint sono un lusso che un ecosistema piccolo non si può permettere spesso.

FAQ

Che cos'è l'ecosistema MCP italiano?

È l'insieme dei server MCP — servizi che espongono dati o strumenti a un modello linguistico in formato standard — costruiti su dati italiani: parlamentari, di bilancio, normativi, scientifici, geografici. È censito in un catalogo pubblico e collaborativo, e comprende progetti indipendenti, comunità e alcune istituzioni.

Esiste un modo sostenibile di finanziare un progetto civico open source?

Il modello che si vede applicato nei casi più maturi è la doppia licenza: codice sotto una licenza open copyleft forte, più una licenza commerciale a pagamento per chi vuole integrarlo in prodotti chiusi. Permette un ricavo senza chiudere il progetto, ed è una delle poche alternative alla dipendenza da bandi.

Meglio un assistente legale che gira in locale o un servizio web?

Dipende da dove sta il valore. Il locale vince su privacy e costo marginale, ed è preferibile quando i documenti non devono uscire dalla macchina. Il servizio web vince quando il valore nasce dall'incrociare fonti diverse e mantenere un corpus aggiornato di continuo, cosa difficile da fare su un computer personale.

Perché due progetti dovrebbero mappare la stessa fonte?

Di solito perché non sapevano l'uno dell'altro: è un sintomo di bassa scopribilità, non di competizione. L'effetto collaterale positivo è che la documentazione dei problemi prodotta da un progetto può correggere bug nell'altro, anche senza alcun contatto diretto.

---

Se stai valutando di costruire su dati pubblici italiani e vuoi capire cosa esiste già prima di riscriverlo, parliamone. Vedi anche cosa significa mettere MCP in produzione e perché i dati pubblici italiani sono difficili da usare.