Chattyduck

ChattyDuck è un prototipo dimostrativo. Un assistente che risponde al cittadino solo sui contenuti certificati dell'ente, esposti tramite un protocollo aperto. Il contenuto vive nel server, mai nel prompt del modello.

Gira su un comune immaginario, il Comune di Paperopoli. L'ente pubblica i propri contenuti attraverso un server MCP. I modelli, Gemini e Claude, rispondono solo sulla base di quei contenuti, citando identificativo e versione di ogni passaggio che recuperano.

L'idea in una riga

Il system prompt definisce solo il comportamento del modello. I contenuti risiedono unicamente nel corpus del server. Se un dato non è nella fonte, l'assistente non lo inventa: dice che non è nelle fonti.

Com'è fatto

Il prototipo è una soluzione .NET divisa per responsabilità. Ogni pezzo fa una cosa sola.

• Duckburg.Registry è il server MCP dell'ente. Espone il tool di ricerca e le risorse del corpus, caricato in memoria in sola lettura. È l'unico che possiede i dati.
• Duckburg.Portal è il portale del Comune, in stile Designers Italia. L'assistente compare come widget su ogni pagina e a schermo intero su /assistente.
• ChattyDuck.Quack è la libreria dell'assistente: l'interfaccia di chat, l'endpoint delle risposte, l'orchestrazione dei modelli.
• ChattyDuck.Models contiene le due implementazioni intercambiabili del modello, Gemini e Claude, e il tracciamento dei consumi.
• ChattyDuck.Mcp è il client MCP verso il Registry, usato dal ponte di Gemini.

I nomi dicono la proprietà. Duckburg è l'ente, e possiede il portale e la fonte. ChattyDuck è l'assistente, che alla fonte si collega.

Due modelli, due modi di collegarsi

Questa è la parte che vale la pena guardare da vicino.

• Gemini non parla MCP in modo nativo. Il portale fa da ponte: traduce i tool del server nel formato che Gemini capisce ed esegue le chiamate per suo conto.
• Claude parla MCP in modo nativo. Si collega direttamente all'endpoint pubblico del server, senza ponte. Gli basta l'indirizzo.

Lo stesso corpus, due strade diverse. Per Gemini ho scritto il ponte. Per Claude non è servito. Dove lo standard aperto è supportato davvero, il lavoro di integrazione sparisce.

Chiunque può collegarsi

Il corpus non è chiuso dentro il mio portale. Qualunque client MCP può consumarlo, puntando all'endpoint pubblico del server. Nella pagina dell'assistente c'è la configurazione pronta da copiare per collegare il proprio chatbot.

È il punto della tesi reso concreto. L'ente espone la fonte una volta sola. Poi ci si collega chi vuole, con l'assistente che preferisce.

Come si prova

L'assistente è online. Le domande di controllo che dimostrano l'ancoraggio alla fonte sono queste:

• "Quando scade la prima rata della TARI?" risponde 30 aprile e cita il passaggio.
• "Quali sono le aliquote IMU?" dà i valori di Paperopoli, citati.
• "Che giorno passa l'umido nel quartiere Vesuvio?" risponde che non è nelle fonti, perché quel quartiere non esiste.
• "Come prenoto la carta d'identità?" riporta la procedura dal corpus.
• La stessa domanda posta a client diversi dà la stessa risposta, ancorata agli stessi passaggi.

Le prime quattro le puoi fare adesso sulla PoC. La quinta la verifichi collegando un tuo client al server.

Cos'è vero e cos'è finto

È simulato il comune, e solo il comune. Le vie, i quartieri, le scadenze. Il resto è reale: il server, il protocollo, i modelli, il modo in cui rispondono.

Tra Paperopoli e un comune vero cambia una cosa sola, il corpus. Non cambia una riga di codice. Cambiano i dati. E scrivere e certificare quei dati è il lavoro dell'ente, non l'informatica.

Il codice è pubblico. Provalo, aprilo, mettilo alla prova.