MCP, API o file Excel? Come collegare l’AI ai dati

Quando sento dire che basta collegare un nuovo strumento all’intelligenza artificiale per farla lavorare sui dati aziendali, io penso al report che qualcuno dovrà discutere in riunione. Non mi basta che la risposta sia chiara o che il grafico sia convincente. Voglio sapere da dove arrivano le informazioni, quanto sono aggiornate e che cosa è successo tra la domanda e la conclusione. Un collegamento può risparmiarci un’esportazione; può anche rendere meno visibile un passaggio che prima controllavamo di persona.

Per questo non partirei dalla scelta fra file, API e MCP come se fossero tre prodotti in competizione. Partirei dal lavoro. Devo analizzare una situazione già chiusa, produrre sempre lo stesso report o interrogare sistemi diversi mentre ragiono? Sono esigenze vicine, ma richiedono controlli differenti. E prima di aggiungere un gateway vorrei capire chi userà gli strumenti, con quali permessi e con quale responsabilità sul risultato. In questa guida seguo lo stesso esempio attraverso le diverse possibilità: un team marketing che deve leggere campagne e contatti commerciali. È un caso didattico, non il racconto di un cliente o di un test svolto.

Prima del collegamento: quale risultato deve produrre il team?

Immaginiamo un responsabile marketing che debba capire se le campagne stanno portando richieste utili. Nelle piattaforme pubblicitarie vede spesa e conversioni; nel CRM, il sistema che raccoglie i rapporti con i clienti, trova contatti, stato delle trattative e valutazioni del commerciale. Vuole un report che metta queste informazioni in relazione e indichi che cosa approfondire. Non vuole ancora cambiare budget o sospendere annunci. Il primo perimetro del lavoro è quindi di lettura e analisi.

La difficoltà non comincia dal protocollo. Comincia dal significato delle colonne. Una conversione della piattaforma potrebbe essere l’invio di un modulo, mentre il commerciale considera qualificata soltanto una richiesta con determinate caratteristiche. Se l’AI trova due numeri diversi, non può decidere da sola che uno dei due sia sbagliato. Potrebbero descrivere momenti differenti dello stesso percorso. Prima di sommarli o confrontarli serve una definizione condivisa.

Anche il collegamento tra i record va dimostrato. Vedere una campagna in un sistema e un contatto nell’altro non significa sapere che quel contatto arrivi da quella campagna. Può servire un identificatore, una regola di attribuzione o un’altra ricostruzione documentata. Se mancano, il risultato corretto è dichiarare il limite. Nessun connettore trasforma una relazione possibile in un fatto osservato.

Io scriverei quindi il risultato atteso prima di scegliere la tecnologia: un riepilogo con periodo, account, valuta, definizioni delle metriche, origine dei dati, data di estrazione, informazioni mancanti e questioni da verificare. Il report dovrà permettere a un’altra persona di rifare il percorso. Questo requisito rimane identico sia che consegniamo un foglio Excel sia che interroghiamo un server MCP.

Tre modi di arrivare ai dati, non tre gradini di maturità

Il file manuale, l’integrazione API e MCP rispondono a domande diverse. Il primo riguarda soprattutto la consegna di materiale. La seconda riguarda l’interazione tra programmi. MCP riguarda un modo condiviso di presentare contesto e capacità alle applicazioni AI. In un processo reale possono convivere: una parte dei dati arriva da un’API, un documento viene caricato a mano e un server rende disponibile una funzione attraverso MCP.

La distinzione conta perché evita una spesa costruita sull’etichetta. Un’integrazione già stabile non deve essere sostituita per apparire più aggiornata. E una prima analisi non deve necessariamente diventare un progetto di infrastruttura. La domanda utile è quale passaggio vogliamo rendere più affidabile, ripetibile o accessibile, sapendo che ogni nuovo collegamento richiede anche manutenzione.

File manuali: una copia controllabile, con una scadenza

Nel percorso più semplice una persona esporta i dati delle campagne e un’altra prepara il materiale del CRM. Prima di caricarli nell’assistente, controlla che il periodo sia quello richiesto, che gli account siano pertinenti e che non siano presenti campi personali inutili. Il file non dovrebbe arrivare da solo: va accompagnato da una spiegazione di che cosa contiene, di come è stato ottenuto e di quali informazioni sono state escluse.

Pensiamo a un foglio con i nomi delle campagne, la spesa e le conversioni. Una colonna chiamata «risultati» è troppo ambigua. L’AI può leggere il nome, ma non può ricostruire una definizione che nessuno le ha fornito. Io aggiungerei una nota che chiarisca quale evento viene contato, quale intervallo temporale è incluso e se ci sono filtri. La qualità del lavoro comincia qui, prima del prompt.

Il vantaggio è la possibilità di delimitare il materiale. Per un’analisi su un periodo concluso può essere utile conservare esattamente la copia su cui abbiamo ragionato. Se il responsabile chiede perché sia stata formulata una conclusione, possiamo riaprire quel pacchetto e vedere quali informazioni erano disponibili. La stabilità della copia è una proprietà utile quando vogliamo ricostruire una decisione.

Il limite è altrettanto concreto. Se il CRM viene aggiornato dopo l’esportazione, la copia caricata non cambia. Per includere l’aggiornamento bisogna estrarre e consegnare nuovamente i dati. Un prodotto può offrire funzioni di sincronizzazione, ma vanno verificate come capacità aggiuntive: non appartengono al semplice caricamento di un file. «L’AI ha i dati» non significa quindi «l’AI ha gli ultimi dati».

Come preparerei il pacchetto di lavoro

Creerei una cartella riconoscibile per quel report. Dentro metterei gli estratti autorizzati e una nota leggibile: sorgente, momento dell’estrazione, periodo analizzato, valuta, significato delle colonne, filtri e problemi noti. Separerei i file ricevuti dalle trasformazioni successive. Se correggo un nome o raggruppo categorie, voglio conservare la possibilità di capire che cosa ho modificato.

Non caricherei più dati soltanto perché lo spazio lo consente. Per confrontare una spesa con la qualità delle richieste potrebbero non servire nomi, email o testi liberi dei contatti. Il luogo di caricamento e le condizioni del servizio vanno considerati prima di consegnare materiale aziendale. Manuale non significa automaticamente privato; significa che una persona compie il passaggio.

Il controllo finale riguarda la lettura. Un file può essere troncato, interpretato con un separatore sbagliato o avere colonne che contengono formati misti. Prima della sintesi chiederei all’assistente quali righe e campi ha effettivamente letto e confrontarei i totali con l’origine. Un report elegante costruito su un estratto incompleto rimane incompleto, anche quando le formule sembrano plausibili.

API: una richiesta progettata, non un ragionamento automatico

Una API, Application Programming Interface, è un’interfaccia che permette a un software di interagire con un altro componente. Nel nostro caso ci interessano soprattutto le API dei servizi aziendali. Come spiega il glossario MDN, l’interazione segue regole e funzionalità messe a disposizione dal software. Non è necessario immaginarla come un’intelligenza che capisce il nostro obiettivo.

Nell’esempio del report, un programma richiede i dati di un account per un intervallo stabilito e riceve una risposta strutturata. Un altro passaggio può richiedere gli stati dei contatti al CRM. Chi progetta l’integrazione deve specificare le informazioni necessarie, interpretare le risposte e decidere che cosa fare se una richiesta non riesce. L’API rende possibile l’accesso previsto; il processo gli dà uno scopo.

Questo lavoro può avvenire senza un modello che decida ogni mossa. Se il report deve sempre raccogliere gli stessi campi, applicare le stesse regole e produrre lo stesso prospetto, una sequenza deterministica può essere appropriata. Deterministica significa che i passaggi sono definiti dal processo, anziché scelti ogni volta durante una conversazione. L’AI può intervenire dopo, per discutere i risultati già preparati.

È una distinzione utile per il marketing. Non ogni attività ripetitiva ha bisogno di un agente che ragioni. A volte serve soprattutto una raccolta affidabile, accompagnata da controlli. Aggiungere libertà di scelta dove il compito è già noto può introdurre variabilità senza un beneficio chiaro. Io userei la conversazione dove serve esplorare o interpretare, e renderei espliciti i passaggi che devono ripetersi uguali.

Che cosa rimane da progettare quando l’API esiste

Un servizio può restituire i risultati in più pagine. Se l’integrazione legge soltanto la prima, il report può sembrare riuscito pur avendo perso una parte dei dati. Può anche incontrare limiti di richiesta, credenziali scadute o campi non più disponibili. Questi casi richiedono un comportamento previsto: segnalare l’incompletezza è diverso dal sostituire un valore mancante con zero.

Anche la freschezza del dato dipende dalla sorgente. Una risposta ricevuta adesso può contenere informazioni aggiornate con ritardo. Oppure il programma può usare una copia temporanea, la cache, per evitare richieste ripetute. L’orario della chiamata e il momento cui si riferisce il dato non coincidono necessariamente. Per questo nel report vorrei entrambi, quando disponibili.

Infine serve qualcuno che avvii il lavoro. Se vogliamo un aggiornamento periodico, occorrono una pianificazione e una gestione dell’esecuzione: che cosa succede se il servizio non risponde, chi viene avvisato, quando si riprova e come si evita di produrre due report contraddittori. La presenza dell’API non crea da sola un’automazione completa. È una componente del progetto, non il progetto intero.

MCP: quali strumenti può usare l’applicazione AI?

MCP, Model Context Protocol, è un protocollo aperto per lo scambio tra applicazioni AI e server che rendono disponibili contesto e capacità. Per immaginare il suo ruolo, torniamo alla conversazione: il responsabile marketing non chiede sempre lo stesso prospetto. Potrebbe volere un dettaglio aggiuntivo su una campagna o una lettura diversa delle richieste. L’applicazione deve sapere quali strumenti sono disponibili e come richiederne l’uso.

Nell’architettura ufficiale, l’host è l’applicazione che ospita l’esperienza AI; il client MCP è il componente attraverso cui interagisce con il server. Il server espone capacità. Non occorre confondere questi ruoli con il modello: il modello partecipa al ragionamento, mentre l’applicazione gestisce concretamente l’interazione con gli strumenti.

Supponiamo che un server esponga una funzione chiamata leggi_report_campagne. Il nome è inventato per questa spiegazione e non identifica un connettore installato. Una descrizione utile dovrebbe indicare che cosa fa, quali parametri richiede e che cosa restituisce. Se serve un periodo e un account, questi devono essere specificati. Non dovrebbe lasciare implicita una scelta capace di cambiare il significato del risultato.

L’applicazione compatibile può richiedere l’esecuzione dello strumento e riceverne il risultato. Dietro il server, il recupero potrebbe usare l’API della piattaforma pubblicitaria. MCP e API possono quindi stare nella stessa catena. MCP organizza un modo di esporre capacità all’applicazione AI; l’API può essere il mezzo usato per interagire con il servizio sottostante. Non sono necessariamente alternative tecniche.

Tool, risorse e prompt: non tutto è un comando

La specifica MCP distingue strumenti, risorse e prompt. Un tool esegue una funzione; una risorsa può fornire contesto; un prompt mette a disposizione una traccia riutilizzabile. Per il nostro report potremmo immaginare una funzione che legge dati e un documento che spiega le metriche. Sono ruoli diversi, entrambi utili a capire una risposta.

La disponibilità effettiva dipende però dal server e dall’applicazione che li usa. Il protocollo non implica che tutti i servizi abbiano già un server adatto, né che ogni client supporti ogni capacità. Prima di progettare il lavoro vorrei vedere che cosa è realmente esposto, quali parametri sono ammessi e quali limiti esistono. Una demo su un’applicazione non dimostra automaticamente lo stesso comportamento su un’altra.

Se manca il campo che serve, non lo considero un problema da risolvere soltanto riscrivendo la domanda. Potrebbe mancare nella sorgente, nell’API, nella funzione esposta o nei permessi. L’assistente dovrebbe rendere visibile l’assenza. La richiesta in linguaggio naturale non aggiunge un dato che il sistema non può ottenere e non autorizza un accesso che non è stato concesso.

In parole semplici: dossier, interfaccia e linguaggio comune

Il file è il dossier che porto a una riunione. Ho scelto il materiale e posso conservarlo, ma se fuori dalla stanza cambia qualcosa devo aggiornare il dossier. L’API è un’interfaccia concordata per chiedere informazioni o operazioni a un sistema. MCP offre un linguaggio comune con cui un’applicazione AI può conoscere e usare capacità esposte da un server.

L’analogia ha un limite: nessuno di questi passaggi certifica ciò che c’è dentro il dossier o la risposta ricevuta. Un dato può essere vecchio, una metrica può avere un significato inatteso e una funzione può restituire meno informazioni di quelle desiderate. Il collegamento è il percorso; la verifica riguarda anche il contenuto che attraversa quel percorso.

Per questo eviterei di dire che MCP «fa parlare direttamente il modello con tutti i software». La frase nasconde applicazione, server, autorizzazioni e trasformazioni. Sembra semplificare, ma toglie proprio i pezzi che un’azienda deve governare. La spiegazione utile consente invece di indicare dove un’informazione è stata scelta, letta, filtrata o modificata.

Il confronto che userei prima di scegliere

Per un’analisi occasionale di un periodo chiuso potrei scegliere il file. Se voglio un prospetto ricorrente con regole stabili, valuterei l’integrazione API e la sua esecuzione programmata. Se voglio esplorare i dati attraverso un’applicazione AI usando capacità disponibili, valuterei MCP. La scelta dipende dal compito; non attribuirei un premio automatico all’ultima tecnologia nominata.

Considererei anche il costo del cambiamento. Un collegamento nuovo richiede configurazione, conoscenza dei sistemi, verifica e manutenzione. La possibilità di ridurre il lavoro manuale è interessante, ma va confrontata con queste attività. In questa guida non presento un listino o una percentuale di risparmio: senza un perimetro misurato, un numero preciso darebbe soltanto una sensazione di certezza.

Un esercizio pratico per confrontare i tre percorsi

Il primo esercizio che propongo non richiede di collegare account di produzione. Serve a definire un risultato verificabile prima di costruire l’accesso. Si può lavorare con estratti autorizzati e privi di informazioni personali non necessarie, oppure con un dataset sintetico dichiarato. Nel secondo caso il materiale serve a esercitarsi sul metodo, non a dimostrare un beneficio commerciale.

Scrivi il risultato e le condizioni prima della richiesta

La consegna del nostro caso è questa: preparare un riepilogo delle campagne e dei contatti qualificati per lo stesso periodo, distinguendo ciò che è osservato da ciò che non possiamo collegare. Il report deve dichiarare se le definizioni non coincidono e quali approfondimenti servono al responsabile. Non deve cambiare nulla nei sistemi né suggerire che un collegamento non documentato sia stato dimostrato.

Metterei per iscritto anche le condizioni di arresto. Se manca il periodo, non faccio finta di conoscere quello giusto. Se la risposta non contiene tutti i risultati, non la tratto come completa. Se non esiste una relazione dimostrabile tra campagne e contatti, posso descrivere le due sorgenti ma non attribuire vendite alle campagne. Queste regole rendono l’esercizio utile anche quando la risposta è «non possiamo ancora concludere».

Lavora soltanto sui materiali e sugli strumenti autorizzati per questo report.
Prima di formulare conclusioni, indica periodo, account, valuta, definizione delle metriche, origine dei dati e momento dell’estrazione, se disponibile.
Controlla quali campi sono presenti e quali informazioni mancano. Non trasformare un valore assente in zero.
Non collegare record di sorgenti diverse senza una chiave o un metodo esplicito. Dichiara i limiti dell’attribuzione.
Separa osservazioni, ipotesi e verifiche da affidare al responsabile. Mostra le trasformazioni necessarie a ricostruire il risultato.
Non modificare campagne, budget, contatti o altri sistemi. Se manca una condizione necessaria, fermati e spiegala.

Esegui prima la verifica del materiale

Nel percorso manuale consegna i file insieme alla nota di contesto. Chiedi una descrizione dei dati prima dell’interpretazione: quali colonne sono state lette, quali categorie compaiono e quale intervallo è presente. Confronta questi elementi con il materiale originario. Non serve chiedere subito un commento strategico; prima devi sapere se l’assistente sta leggendo il pacchetto che pensi di avergli dato.

Se trovi una differenza, documentala e correggi la causa. Potrebbe essere un’esportazione filtrata o un campo spiegato male. Chiedere soltanto «ricontrolla meglio» non ti dice dove il processo si è rotto. L’obiettivo dell’esercizio è uscire con una definizione più precisa del lavoro, non con un prompt sempre più lungo che copra ogni possibile sorpresa.

Trasforma la consegna in un requisito per l’integrazione

Per il percorso API, la stessa scheda diventa una specifica. Chi realizza il collegamento deve sapere quali account interrogare, quali campi recuperare, come riconoscere l’incompletezza e come documentare le trasformazioni. Il risultato non dovrebbe essere soltanto una tabella: dovrebbe contenere anche le informazioni necessarie a capire se quella tabella è utilizzabile.

Per il percorso MCP chiederei di vedere l’elenco delle capacità effettivamente esposte, i parametri e un esempio di risposta consentita. Poi confronterei il materiale ottenuto con la sorgente, senza dare per scontato che il nome del tool garantisca la copertura desiderata. leggi_report_campagne può essere un nome chiaro e restituire comunque un sottoinsieme non adatto alla domanda. È il contratto della funzione che dobbiamo verificare.

Consegna una scheda di verifica, non soltanto una conclusione

L’output finale dell’esercizio comprende il riepilogo e una scheda con provenienza, copertura, campi mancanti, trasformazioni, controlli effettuati e decisioni ancora aperte. Se un’altra persona non può distinguere il dato originario dalla nostra interpretazione, la consegna non è ancora pronta per una scelta importante.

Questo è il legame con la strategia digital con ChatGPT: la qualità delle domande e dei materiali precede la sintesi. Nel workflow con ChatGPT, Claude e Gemini, distinguere produzione e critica aiuta a discutere un risultato senza scambiare l’accordo tra modelli per una prova. La content factory con controllo umano aggiunge un altro pezzo: ciò che si automatizza deve avere un responsabile e una capacità reale di revisione.

Leggere non è modificare: dove metterei i confini

Nel nostro esempio abbiamo bisogno di leggere dati e ragionare. Non serve per questo autorizzare modifiche ai budget. Separare le capacità riduce anche l’ambiguità della consegna: un conto è proporre una correzione, un altro è applicarla. Un processo che usa tool di scrittura deve stabilire quali azioni sono ammesse, come si controllano e quando serve una decisione umana.

Distinguerei poi l’identità dal permesso. Sapere quale utente si è collegato non significa che qualunque operazione sia appropriata. Il contesto dell’account, il cliente, il periodo e l’azione devono rientrare nel perimetro previsto. Le pratiche di sicurezza MCP trattano anche problemi legati a proxy, credenziali e accessi: la presenza di un intermediario richiede controlli, non li rende superflui.

Un altro confine riguarda le istruzioni contenute nei materiali. Una nota esterna può cercare di convincere l’assistente a ignorare il compito e trasmettere informazioni altrove. È il tipo di problema indicato come prompt injection. Per il team significa non trattare ogni testo letto come un comando affidabile. La richiesta scritta nella chat non sostituisce permessi limitati e controlli sulle operazioni realmente eseguibili.

Nella verifica del progetto chiederei anche come si riconosce un fallimento. Un errore esplicito è più gestibile di un report che sembri completo senza esserlo. Voglio sapere se un tool ha letto solo una parte dei dati, se l’accesso è scaduto o se una trasformazione ha escluso record. La trasparenza non è un dettaglio da aggiungere alla fine: determina quanto possiamo fidarci della consegna.

MCP gateway: quando il collegamento diventa un problema di gestione

Fin qui abbiamo ragionato su un’applicazione e sulle capacità che le servono. Immaginiamo ora che diversi team usino applicazioni differenti e che ogni gruppo debba raggiungere più server. Le configurazioni possono moltiplicarsi; diventa più difficile capire quali strumenti siano disponibili, chi abbia accesso e dove osservare le chiamate. È a questo livello che valuterei un gateway.

Un MCP gateway è un intermediario tra client e server, con funzioni che dipendono dall’implementazione. Non è un modello più intelligente, né un componente obbligatorio di ogni progetto MCP. Può centralizzare una parte della gestione, ma va valutato rispetto al problema concreto: distribuire configurazioni, controllare l’accesso o seguire le operazioni sono esigenze diverse da «ottenere una risposta migliore».

La documentazione del gateway Docker descrive gestione di configurazioni, credenziali e accessi, instradamento e ciclo di vita dei server, con isolamento e tracciamento delle chiamate. La stessa pagina distingue condizioni di accesso per funzioni legate ad AI Governance. Non leggerei quindi la parola gateway come promessa che ogni installazione includa tutti i controlli aziendali desiderati.

La scelta aggiunge responsabilità. Chi aggiorna il gateway? Chi verifica che la politica di accesso corrisponda ai ruoli? Quali informazioni finiscono nei log e per quanto tempo vengono conservate? Che cosa succede se quel punto intermedio non è disponibile? Una gestione centralizzata può aiutare, ma concentra anche una parte del lavoro operativo. Per un primo esercizio con un solo server potrei non averne bisogno.

Le frontiere MCP: che cosa è documentato oggi

Alla verifica del 2 novembre 2026, la pagina ufficiale della specifica indicata come corrente rimanda alla versione 2026-07-28. È importante dirlo perché una guida può mescolare documenti di periodi diversi e descrivere come universale un comportamento cambiato. L’annuncio della release del 28 luglio presenta un core senza stato, richieste autosufficienti, instradamento tramite header e risultati di elenco memorizzabili in cache.

In parole pratiche, una richiesta che contiene le informazioni necessarie alla sua gestione può facilitare il lavoro dell’infrastruttura che la riceve e la instrada. «Senza stato» riguarda il protocollo: non significa che un CRM smetta di conservare dati o che un’applicazione dimentichi tutto. Il cambiamento tecnico non va trasformato in uno slogan sulla scomparsa della memoria. Prima di adottarlo bisogna verificare versioni e compatibilità dei componenti effettivamente usati.

La release formalizza anche un sistema di estensioni. Questo rende ancora più importante distinguere capacità documentata e supporto nel prodotto: trovare un’estensione non dimostra che il proprio client e il server scelto la implementino. Per un team la domanda non è soltanto «esiste?», ma «possiamo usarla in questo processo, con questi controlli?».

Tasks: seguire un lavoro che non finisce subito

L’estensione MCP Tasks permette di gestire operazioni lunghe attraverso un identificatore persistente e consultazioni dello stato fino al risultato. Richiede supporto esplicito delle parti coinvolte. Nel caso del report, può essere pertinente quando una lavorazione non si conclude nella prima risposta. Non equivale a dare al sistema un calendario, una responsabilità o un obiettivo autonomo: questi elementi restano da progettare.

La conseguenza operativa che mi interessa è la possibilità di separare «richiesta accettata» da «lavoro concluso». Sono eventi diversi. Un team dovrebbe poter riconoscere che cosa è ancora in corso, che cosa richiede un intervento e quale risultato sia definitivo. Questa distinzione serve anche senza usare MCP: l’estensione dà una forma tecnica a un problema di processo che dobbiamo comunque capire.

MCP Apps: interagire con il risultato nella conversazione

Le MCP Apps consentono di presentare interfacce interattive in host compatibili. Nel nostro esempio, la prospettiva è esplorare i dati insieme alla conversazione invece di ricevere soltanto una descrizione. Anche qui bisogna verificare supporto, operazioni accessibili e confini dell’interfaccia. La presenza di una tabella interattiva non prova che i dati siano completi o che la decisione sia corretta.

La mia lettura è che queste evoluzioni rendano più importante la progettazione del lavoro, non meno. Quando l’assistente può chiedere dati, avviare una lavorazione e presentare un’interfaccia, il percorso diventa più ricco. Deve però restare leggibile. Voglio poter ricostruire come una richiesta è diventata un’operazione e come quell’operazione ha prodotto il risultato che sto guardando.

Da dove partirei, senza costruire più di quanto serve

Per il nostro team partirei da una consegna circoscritta e in sola lettura. Preparerei un esempio verificabile, chiarirei le metriche e confronterei il risultato con le sorgenti. Se il problema è soprattutto raccogliere sempre gli stessi dati, investirei nella ripetibilità. Se emerge il bisogno di interrogarli in modo flessibile attraverso un’applicazione AI, valuterei le capacità MCP disponibili. Il gateway arriverebbe quando configurazioni e accessi richiedono davvero un punto di gestione.

Non trasformerei questo percorso in una prescrizione uguale per tutti. Un’azienda può avere già una base dati affidabile; un’altra può non sapere ancora che cosa significhi una colonna nel proprio report. Nel primo caso il collegamento può essere il passo utile; nel secondo rischia di accelerare una confusione. È il motivo per cui, nella mia lettura, il numero di strumenti connessi non misura la maturità di un sistema decisionale.

Il criterio conclusivo è semplice da formulare, ma richiede lavoro: dove si trova il dato, chi lo richiede, chi può agire, che cosa viene trasformato e chi verifica il risultato? Se il team sa rispondere, può scegliere file, API o MCP con un motivo. Se non sa rispondere, il nuovo collegamento può rendere il processo più veloce senza renderlo più comprensibile. Io vorrei ottenere entrambe le cose, prima di chiamarlo un miglioramento.

FAQ

MCP sostituisce le API?

No. Un server MCP può usare le API di un servizio per esporre capacità a un’applicazione AI. MCP organizza lo scambio di contesto e strumenti; l’API può essere l’interfaccia verso la sorgente. I due possono convivere nello stesso processo.

MCP garantisce dati aggiornati in tempo reale?

No. La freschezza dipende dalla sorgente, dal comportamento dello strumento e da eventuali copie temporanee. Il momento della richiesta non coincide necessariamente con il momento cui si riferiscono i dati. Occorre verificare e dichiarare queste condizioni.

Serve un MCP gateway per iniziare?

Non necessariamente. Va valutato quando più collegamenti richiedono gestione di configurazioni, accessi o instradamento. Le funzioni dipendono dal prodotto scelto. Un primo caso con un solo server può funzionare senza questo intermediario.

Collegare l’AI significa permetterle di modificare i sistemi?

No. Lettura e scrittura sono capacità differenti. Il progetto deve esporre solo le operazioni necessarie e applicare permessi adeguati. Una proposta formulata dall’assistente non deve diventare automaticamente una modifica a campagne o dati aziendali.

Serve programmare per usare MCP?

Non sempre: alcune applicazioni offrono collegamenti configurabili. Disponibilità, capacità e condizioni vanno verificate nel prodotto concreto. Realizzare o mantenere un server e un’integrazione può invece richiedere competenze tecniche. L’assenza di codice nell’interfaccia non elimina il lavoro di verifica.

Fonti, metodo e autrice

Guida formativa con fonti tecniche primarie verificate il 2 novembre 2026. Il caso marketing, i nomi delle funzioni e l’esercizio sono illustrativi; non descrivono test eseguiti, dati di clienti o risultati misurati. Gli schemi sono realizzati in codice e rappresentano percorsi concettuali, non statistiche. La posizione e il criterio operativo esprimono il ragionamento di Giorgia; il supporto alle funzionalità deve essere verificato nei prodotti scelti.

Sono Giorgia Palazzo, consulente, imprenditrice e docente. Collego strategia, dati, AI e implementazione tecnologica alle decisioni delle aziende. Qui spiego come leggere un’architettura prima di adottarla, rendendo espliciti criteri, limiti e responsabilità.