Un server MCP dentro il gestionale: uno studio del lavoro ha smesso di copiare e incollare

In uno studio di consulenza del lavoro abbiamo collegato un server MCP al gestionale. Da quel momento le skill di generazione documenti che lo studio usava già leggono i dati di aziende e dipendenti direttamente alla fonte, dentro il perimetro dello studio. Il copia e incolla dal gestionale al documento è sparito.

È un intervento piccolo e molto concreto, ma mostra bene dove sta il valore di un harness in uno studio professionale. Non nel sostituire il software che c’è, e nemmeno nel sostituire chi ci lavora: nel togliere di mezzo il trasporto manuale dei dati da un sistema all’altro.

Il lavoro che sta fuori dal gestionale

Un gestionale paghe fa bene ciò per cui è nato: elaborare cedolini, denunce, certificazioni. Intorno a quel nucleo resta però una fascia larga di lavoro che nessun modulo copre. Lettere di assunzione, comunicazioni al dipendente, riepiloghi per il cliente, note per la contabilità.

Quel lavoro si fa a mano, e si fa quasi sempre nello stesso modo. Si apre il gestionale, si cerca l’azienda, si cerca il dipendente, si copiano ragione sociale, codice fiscale, sede, mansione, livello, data di decorrenza. Si incolla tutto in un modello. Poi si rilegge, perché nel copia e incolla qualcosa scivola sempre.

Il problema non è solo la lentezza. Ogni passaggio manuale è un punto in cui il dato può cambiare senza che nessuno se ne accorga, e uno studio del lavoro risponde di quei dati.

Che cos’è un server MCP

Il Model Context Protocol è uno standard aperto che descrive come un modello linguistico può chiedere dati e azioni a un sistema esterno. Un server MCP è il pezzo che sta dalla parte del sistema: espone un elenco preciso di strumenti e, per ciascuno, dichiara cosa fa, quali parametri accetta e cosa restituisce.

La differenza rispetto a un’integrazione tradizionale è che il contratto è scritto per essere letto da un modello, non solo da un programmatore. Per lo studio la conseguenza pratica è una sola: il modello non ha più bisogno che qualcuno gli porti i dati sotto il naso. Li chiede.

Cosa abbiamo esposto, e soprattutto cosa no

La parte impegnativa di un progetto così non è collegare il gestionale. È decidere cosa il server non deve poter fare. Un server MCP troppo generoso è un modo elegante per far uscire dati che non dovevano uscire.

Strumenti esposti

• lettura dell’anagrafica azienda: ragione sociale, sede, codice fiscale, CCNL applicato
• lettura dell’anagrafica dipendente, sempre limitata a una specifica azienda
• lettura degli elementi del rapporto di lavoro: qualifica, livello, orario, decorrenza

Strumenti deliberatamente non esposti

• qualunque scrittura: il server è in sola lettura, non può modificare nulla nel gestionale
• dati retributivi puntuali e qualsiasi dato che tocchi la salute della persona
• ricerche libere sull’intero archivio, che sono la scorciatoia più rapida verso una fuga di dati

Ogni strumento accetta parametri stretti e restituisce solo i campi che servono a comporre il documento. Se una skill chiede un dipendente, deve dire di quale azienda: non esiste una chiamata che restituisca tutti i dipendenti di tutti i clienti.

L’innesto sulle skill che lo studio usava già

Questo è il motivo per cui il progetto è stato veloce. Lo studio non partiva da zero: usava già delle skill di generazione documenti, cioè istruzioni scritte che descrivono come si compone una lettera di assunzione, con quale struttura, quali clausole e quale tono.

Quelle skill funzionavano bene, ma erano cieche. Chi le usava doveva incollare a mano i dati nel prompt, e il risultato era buono quanto la trascrizione che lo precedeva.

Collegare il server MCP non ha cambiato le skill. Ha cambiato da dove prendono i dati. La competenza dello studio, sedimentata in quelle istruzioni nel corso del tempo, è rimasta dov’era: abbiamo aggiunto solo la capacità di andarsi a prendere i fatti.

Un harness non sostituisce il sapere di uno studio. Lo collega ai dati su cui deve lavorare.

Dove finiscono i dati

È la prima domanda che pone chiunque tratti dati di dipendenti, ed è la domanda giusta. Le risposte, in questo caso, sono quattro.

1. Il server gira nell’infrastruttura dello studio. I dati non vengono copiati altrove né usati per addestrare alcun modello.
2. L’accesso è in sola lettura. Nessuna chiamata può alterare il gestionale.
3. Ogni chiamata è registrata: quale strumento, con quali parametri, per conto di quale operatore e quando. Il registro è consultabile.
4. Vale il principio di minimizzazione: ogni strumento restituisce il minimo indispensabile a comporre quel documento, non tutto ciò che il gestionale saprebbe dire.

Il perimetro non è un dettaglio tecnico da mettere in fondo al contratto. In uno studio professionale è la condizione perché il progetto sia accettabile.

Cosa è cambiato nella pratica quotidiana

Chi prepara il documento non trascrive più. Descrive cosa serve, verifica quello che esce e firma. Il tempo si sposta dalla trascrizione alla verifica, che è l’unica parte in cui la competenza di un consulente del lavoro conta davvero.

Gli errori di trascrizione, poi, non diminuiscono: spariscono per costruzione, perché non esiste più un passaggio in cui una persona ricopia un codice fiscale.

Una precisazione onesta sui numeri. Non abbiamo ancora una misura pubblicabile del tempo risparmiato. La stiamo raccogliendo insieme allo studio e la pubblicheremo quando sarà un dato e non un’impressione. Preferiamo un caso senza percentuali a una percentuale senza misura.

Quando non conviene farlo

Un server MCP sul gestionale non ha senso ovunque. Sconsigliamo di partire quando ricorre una di queste condizioni.

• I documenti da produrre sono pochi e sempre uguali: un modello con i segnaposto costa meno e rende lo stesso.
• I dati non stanno in un sistema interrogabile ma in fogli di calcolo sparsi: prima va sistemata quella parte, altrimenti si automatizza il disordine.
• Ogni singolo passaggio richiede una valutazione professionale: se non c’è nulla di ripetitivo, non c’è nulla da imbracare.

Cosa serve per rifarlo

1. Un gestionale che esponga i dati in modo interrogabile, via API o via database in lettura.
2. Una mappa scritta di quali dati servono per ciascun documento, ricavata parlando con chi quei documenti li prepara.
3. Un elenco chiuso di strumenti, con i confini decisi prima di scrivere il codice.
4. Un registro delle chiamate attivo dal primo giorno, non aggiunto dopo.
5. Una serie di casi di prova che vengano rieseguiti a ogni modifica, compresi i casi che il sistema deve rifiutare.

L’ultimo punto è quello che di solito viene saltato, ed è quello che distingue un progetto in esercizio da una dimostrazione riuscita una volta sola.