MCP spiegato: come funziona Model Context Protocol

Gli LLM possono chiamare strumenti già da tempo, ma Model Context Protocol (MCP) introduce un modo strutturato e standardizzato per farlo.

Tuttavia, c’è ancora confusione su cosa sia davvero MCP.

Molti pensano che MCP sia un’app, un’API o uno strumento, ma non è nessuna di queste cose. È un protocollo, e questo ha un significato molto preciso.

Vediamolo nel dettaglio.

Se vuoi solo vedere cosa permette MCP nella pratica, guarda questo breve video:

Che cos’è un protocollo?

Un protocollo è semplicemente un insieme di regole che definiscono come due o più sistemi comunicano tra loro.

Da solo non fa nulla. Definisce solo la struttura e le aspettative di una conversazione tra due entità. Consideralo un linguaggio condiviso con regole grammaticali rigide che i computer seguono per scambiarsi informazioni.

I sistemi postali fanno qualcosa di simile. Tutti gli uffici postali di un determinato paese seguono un formato di indirizzo standardizzato per inviare lettere.

Oppure puoi pensarlo come USB-C per gli strumenti AI. Vent’anni fa, il mercato era pieno di diversi tipi di cavi di ricarica e dati. Allo stesso modo, gli ecosistemi AI hanno avuto più modi per passare strumenti ai modelli linguistici. Framework come LangChain, Haystack e Pydantic AI hanno tutti definito i propri formati per integrare strumenti, il che significa che, se uno sviluppatore voleva scrivere un set di strumenti per Google Maps, doveva farlo per ogni tecnologia specifica.

Per rendere il concetto più concreto, consideriamo il protocollo più diffuso, HTTP (Hypertext Transfer Protocol), che fa funzionare i siti web. HTTP definisce, tra le altre cose, come un browser (client) richiede una pagina web a un server web e come il server deve rispondere.

Ecco un esempio di ciclo richiesta-risposta HTTP:

1. Il browser effettua una richiesta HTTP

Quando digiti https://example.com nel browser, il browser invia una richiesta HTTP strutturata al server web:

Ecco i parametri e i valori HTTP usati nel nostro esempio:

"GET" – Questa è l'azione (richiesta di una pagina web).
"/index.html" – La pagina web specifica richiesta.
"HTTP/1.1" – La versione del protocollo utilizzata.
"Host: example.com" – Il nome di dominio del sito web.
"User-Agent: Mozilla/5.0" – Informazioni sul browser che effettua la richiesta.

Il server web sa come interpretare questa richiesta perché HTTP standardizza questo formato. Comprende questo “linguaggio.”

2. Il server risponde usando il protocollo HTTP

Il server elabora la richiesta e restituisce una risposta HTTP strutturata:

"HTTP/1.1 200 OK" – Il codice di risposta (200 significa successo).
"Content-Type: text/html" – Il tipo di contenuto restituito.
"Content-Length: 512" – La dimensione della risposta.
Contenuto HTML – Il contenuto effettivo della pagina web (c'è solo un titolo "Welcome to Example.com")

Importante: HTTP in sé non archivia pagine web e non le visualizza. Definisce solo le regole con cui browser web e server web possono comunicare. Qualsiasi sistema che segue queste regole può comunicare sulla rete Internet definita da HTTP.

Come funziona MCP come protocollo

Ora applichiamo lo stesso ragionamento a MCP (Model Context Protocol).

MCP è un protocollo che consente agli agenti AI di parlare con strumenti e origini dati esterni. Come HTTP, non archivia dati e non esegue attività da solo. Definisce semplicemente un modo standardizzato con cui l’AI può richiedere e recuperare informazioni dagli strumenti.

Cosa sono questi “strumenti”?

Nel contesto degli LLM, gli strumenti sono sistemi esterni, API o servizi con cui l’AI può interagire per estendere le proprie capacità oltre la sola generazione di testo. Consentono agli agenti AI di recuperare dati in tempo reale, prenotare appuntamenti o inviare messaggi ai tuoi amici, rendendoli molto più utili per esigenze del mondo reale.

Supponiamo che tu chieda a un agente AI:

“Che ore sono a Londra in questo momento?”

Poiché l’AI non conosce da sola la risposta corretta, dato che i modelli AI hanno una data limite di conoscenza (ottobre 2023 per i modelli di OpenAI), deve recuperare dati aggiornati da un servizio orario. Ma invece di usare HTTP per richiedere una pagina web, l’AI usa MCP per richiedere dati sull’ora.

Ecco cosa succede:

1. L’agente AI effettua una richiesta MCP al servizio orario (esempio)

"method": "tools.call" → L'AI sta chiamando uno strumento esterno.
"tool": "get_time" → Il nome dello strumento che vuole usare.
"args": { "location": "London" } → I parametri di input specifici.

Proprio come in HTTP, questa richiesta segue un formato rigido, così qualsiasi strumento compatibile con MCP sa esattamente come interpretarla.

2. Il server orario MCP risponde

Lo strumento esterno (server orario) segue le regole di risposta di MCP e restituisce:

"status": "success" → Conferma che la richiesta è stata elaborata correttamente.
"result" → Contiene i dati effettivi sull'ora.

Ora l’agente AI può prendere questi dati e comporre una risposta effettiva per l’utente con:

“L’ora attuale a Londra è 12:20 PM (GMT).”

Per riassumere e chiarire la confusione:

“MCP è un’app.” → No, MCP è un insieme di regole. Per usarlo davvero ti servono software AI e strumenti che implementano MCP, proprio come l’app Instagram ha bisogno di server Instagram attivi per rispondere alle richieste HTTP e fornire dati.

“MCP è un database.” → No, MCP non archivia dati. Aiuta gli agenti AI a parlare con database o API.

“MCP è come un’API.” → Non esattamente. Un’API è un modo specifico per interagire con un sistema, mentre un protocollo (come MCP o HTTP) definisce un modo universale con cui molti sistemi diversi possono comunicare. MCP è un linguaggio che un sistema AI può usare per interagire con molte API reali (orario, database, Stripe, Slack e così via).

Perché MCP è interessante

Ora che sappiamo che MCP è un modo standardizzato con cui il software AI interagisce con strumenti e app esterni, e che MCP non è un’API, vediamo perché la comunità degli sviluppatori AI (noi inclusi) ne è stata entusiasta.

Poiché MCP non è un’API, ma permette invece alle app AI di interagire con API reali su larga scala, aiuta i progetti che devono connettersi a molti sistemi esterni a partire più rapidamente. Gli strumenti danno anche portata a un modello, e ciò che è successo nell’incidente OpenAI Hugging Face mostra cosa accade quando quella portata supera il compito. Per farlo, gli sviluppatori a volte avrebbero dovuto affrontare un intero ciclo di sviluppo di integrazione API, ma oggi di solito usano librerie esistenti o progetti open-source (per esempio disponibili su GitHub) che forniscono la funzionalità necessaria.

Usare queste librerie accelera lo sviluppo, ma integrarle correttamente con il tuo sistema (se non è compatibile con l’implementazione trovata su GitHub) richiede comunque lavoro per far funzionare lo strumento con l’AI.

Con MCP, una volta predisposto il framework, aggiungere una nuova integrazione (per esempio integrare Google Drive) può ridursi a connettersi al server MCP di Google Drive con poche righe di codice. Non incontrerai problemi di compatibilità perché entrambi usate lo stesso protocollo: MCP.

Confrontiamo entrambi gli approcci per vedere più chiaramente le differenze.

Integrazione standard vs uso di Model Context Protocol (MCP)

Per rendere concreto questo confronto, vediamo come aggiungere l’accesso ai file di Google Drive a un agente AI, prima manualmente e poi con uno strumento compatibile con MCP.

Integrazione standard

1. Trovare e adattare una libreria: Cerchi un client API per Google Drive o un progetto open-source. Google fornisce librerie client (per esempio Google Drive API per Python), che includi nel tuo progetto. Devi comunque assicurarti che funzioni nell’ambiente della tua AI.

2. Implementare la logica: Scrivi funzioni per, ad esempio, cercare file o recuperare un documento da Drive. Quando l’AI ha bisogno di qualcosa, deve chiamare queste funzioni. Formatti la richiesta dell’AI in chiamate API specifiche per Google Drive. Dopo aver ricevuto una risposta da Google, estrai il contenuto da reinserire nel contesto dell’AI.

3. Gestire errori e casi limite: Aggiungi codice per gestire casi come “file non trovato,” errori di autorizzazione o limiti di frequenza dell’API. Se l’API di Google restituisce un errore, lo intercetti e magari rispondi con un messaggio di scuse o chiedi all’AI di riformulare. Devi anche evitare che la tua AI invii troppe richieste troppo rapidamente.

4. Mantenere: Nel tempo, se Google aggiorna la propria API o la libreria, devi aggiornare il tuo codice. Se trovi un bug nella libreria, potresti dover applicare una patch o trovare un’altra fonte. In sostanza diventi il manutentore di questa integrazione Google Drive all’interno della tua applicazione AI.

Questo processo si estende ad altri strumenti: vuoi aggiungere Slack o un database alla tua AI? Devi ripetere l’intero processo per ciascuno.

Integrazione MCP

Ora vediamo come apparirebbe quel processo usando MCP.

Prima definiamo i concetti chiave:

Client – un’applicazione AI (ChatGPT, Claude app, Quickchat AI) che stabilisce una connessione con uno o più server e richiede informazioni o azioni per eseguire attività richieste da un utente.

Server – Ogni server può connettersi a qualcosa come un database, un’API (Google Drive) e definire un insieme di “strumenti” o dati che può fornire. In questo caso, il server è un programma che espone questi strumenti e capacità al Client (app AI).

Gli sviluppatori, a seconda di ciò che vogliono fare, possono scegliere di stare da una delle due parti: creare un server per esporre dati, oppure creare un client AI che possa parlare con qualsiasi server. La maggior parte vuole la seconda opzione, ma iniziamo comunque dal lato server per capire passo dopo passo come funziona MCP:

• Inizializzazione di un server MCP. Uno sviluppatore o un amministratore di sistema configura un server MCP per un determinato strumento o origine dati. Un server MCP di solito è solo un piccolo programma che implementa la specifica MCP. Per esempio, è disponibile un server Google Drive MCP precompilato che sa cercare e recuperare documenti.

  Quando inizializzi il server, gli concedi l’accesso al sistema di destinazione (Google Drive). Il server espone poi un insieme di strumenti corrispondenti ad azioni o query che può gestire. È essenzialmente un adattatore API che parla MCP da un lato e il servizio nativo dall’altro.

  Una volta avviato, il server attende richieste.

• Connessione di un LLM (client) a un server MCP. Successivamente, l’applicazione AI (il lato “client”) deve connettersi a quel server. In pratica, se usi una piattaforma AI che supporta MCP (come Claude Desktop), la configureresti con l’indirizzo o il comando per avviare il server. Una volta connesso, il client stabilisce una sessione con il server seguendo l’handshake di MCP. Se usi l’interfaccia di Claude, vedresti che Claude è “connesso” a determinati server MCP (l’interfaccia potrebbe indicare i connettori disponibili).

Ecco come appare nella UI di Claude

• Individuazione degli strumenti disponibili. Con la connessione stabilita, la prima cosa da fare è scoprire cosa offre il server (a volte succede automaticamente dopo la connessione al server). Il client MCP invia una richiesta tools/list al server (questo è definito nel protocollo). Il server risponde con un elenco dei suoi strumenti disponibili, ciascuno con dettagli come nome, descrizione e schema di input.

  Per esempio, un server potrebbe rispondere che dispone degli strumenti create_file(path, content), read_file(path) e search_files(query). Il client rende poi queste informazioni disponibili all’LLM. In molte implementazioni, il client formatterà queste descrizioni degli strumenti e le includerà nel contesto del modello (per esempio aggiungendole al prompt di sistema: “Hai accesso ai seguenti strumenti… [elenco strumenti]”).

Ecco un prompt di sistema AI insieme al messaggio dell’utente che richiede l’ora attuale

Con gli strumenti MCP implementati, viene integrato uno strumento chiamato “get_current_time”, che consente all’AI di accedere a una risorsa esterna e recuperare l’ora esatta a Londra

Questo significa che non devi prevedere e programmare in anticipo tutte le azioni potenziali che la tua app AI potrebbe dover completare per svolgere un’attività. Con MCP, l’AI può scoprire al volo tutte le azioni possibili chiedendole a un server MCP e scegliere ciò che serve.

• Uso di uno strumento tramite MCP. Quando l’AI deve eseguire un’azione o recuperare dati, invoca uno strumento tramite MCP. Dal punto di vista dell’AI (soprattutto per modelli come Claude che supportano nativamente l’uso di strumenti), deciderà nel proprio ragionamento: “Dovrei chiamare lo strumento X con questi parametri.” Il client MCP intercetta quell’intenzione e invia una richiesta tools/call nel formato MCP al server appropriato (server MCP di Google Drive).

• Il server MCP agisce da ponte. Riceve dall’agente AI una richiesta strutturata e conforme a MCP, la mappa sull’endpoint corretto dell’API Google Drive, riscrive la richiesta in una vera chiamata API Google Drive, esegue la richiesta, elabora la risposta e la riformatta di nuovo in una risposta conforme a MCP prima di inviarla all’agente AI.

  Vale la pena notare che i server MCP seguono un approccio strutturato alla gestione degli errori, assicurando che gli agenti AI possano interpretarli e agire di conseguenza in modo efficace.

  Supponiamo che un agente AI stia usando uno strumento MCP per trovare un file in Google Drive. Se la richiesta include un ID file non valido (per esempio una stringa lunga cinque caratteri invece del formato previsto), il server MCP restituirà un messaggio di errore:

  Invece di fallire semplicemente, l’agente AI può prendere questa risposta strutturata e riformularla in un feedback comprensibile per l’utente:

  “Sembra che l’ID file che hai fornito sia troppo corto. Gli ID file di Google Drive sono in genere lunghi 28 caratteri. Puoi controllare e riprovare?”

  Questo approccio assicura che gli errori non portino a vicoli ciechi, ma diventino invece opportunità per guidare l’utente verso una soluzione corretta.

• Rispondere alla domanda/richiesta dell’utente. Una volta che il server MCP restituisce un risultato, il client MCP passa quei dati all’app AI. Il modello poi incorpora il risultato nel proprio ragionamento o direttamente nell’output che genera per l’utente.

  Se l’utente richiede la creazione di un nuovo file Google Sheets, la risposta del server (contenente l’ID file e un link generato) verrà fornita al modello. Il modello risponderà quindi all’utente con: “Buone notizie! Il tuo nuovo file Google Sheets è pronto. Puoi accedervi qui: [link].”

Durante tutto questo processo, l’AI mantiene il controllo del flusso: decide quando chiamare uno strumento e come usare il risultato per formulare la risposta. Nel frattempo, lo sviluppatore non deve orchestrare manualmente questi passaggi, perché il framework MCP e il modello AI li gestiscono. Il risultato finale è che l’utente può porre all’AI domande o attività complesse che richiedono informazioni o azioni esterne, e l’AI può eseguirle autonomamente tramite MCP e restituire un risultato.

Vantaggi dell’uso di MCP

Nota come questo approccio astrae molti dettagli: il client non ha gestito chiavi API o codici di stato HTTP, perché se ne occupa il server MCP.

Il punto principale è la semplicità nel punto di integrazione: “chiediamo” i clienti e li otteniamo. La logica di come recuperarli è incapsulata altrove. Significa che uno sviluppatore che lavora sul lato AI non deve scrivere nuove chiamate HTTP per ogni nuova azione, deve solo invocare gli strumenti per nome. Il lavoro pesante (autenticazione, chiamata agli endpoint di Google Drive, formattazione della risposta) viene svolto nel codice del server MCP, che è riutilizzabile e standardizzato.

Ecco un riepilogo dei vantaggi principali:

• Riduce il codice di collegamento specifico delle API. Prima di MCP, far usare a un’AI un servizio esterno richiedeva in genere la scrittura di molto codice di “collegamento”: chiamare l’API, trasformare la risposta in testo che il modello potesse elaborare, poi analizzare l’output del modello per magari chiamare un’altra API, e così via. Con MCP, gran parte di questo codice viene eliminata. Il client del modello e il server gestiscono lo scambio di dati in modo strutturato, quindi non devi trasformare manualmente altri formati (come JSON) in testo o viceversa, lo fa il protocollo. Inoltre, non devi scrivere logica per decidere quando chiamare cosa. Lo fa l’AI (guidata dalle descrizioni degli strumenti e dal proprio ragionamento o prompt).

• Connettori riutilizzabili e condivisi invece di wrapper API una tantum. Con MCP, scrivi un’integrazione una volta e puoi riutilizzarla in molti progetti e sistemi AI. Per esempio, potresti creare un server MCP per la wiki interna della tua azienda. Qualsiasi app AI che supporta MCP può connettersi a quell’unico server per interrogare la wiki. Non devi reimplementare la “ricerca wiki” per ogni nuovo chatbot AI o per ogni diverso fornitore di LLM. Questa riutilizzabilità rappresenta un cambiamento rispetto al passato, in cui ogni team poteva scrivere la propria integrazione leggermente diversa per la stessa API. MCP incoraggia una libreria di connettori che possono essere condivisi e migliorati collettivamente.

• Integrazione plug-and-play con diversi LLM. MCP è indipendente dal modello. Al protocollo non importa se il client è Claude, GPT-4, DeepSeek o un modello futuro, purché il client possa gestire l’interfaccia MCP. In futuro, se vuoi passare a un altro modello, puoi farlo senza riscrivere tutte le integrazioni.

• Manutenzione più semplice. Poiché è uno standard aperto, esiste una comunità crescente che contribuisce server precompilati (per database, API popolari e così via) che puoi usare invece di costruire tutto da zero. Man mano che integri più sistemi, MCP aiuta a evitare lo “spaghetti” di molte integrazioni punto-punto. E non devi monitorare tutti gli aggiornamenti API degli altri provider.

Le integrazioni API diventeranno obsolete?

Sia le integrazioni API tradizionali sia MCP hanno il proprio ruolo. L’approccio migliore può dipendere dalla natura del progetto, dall’esperienza del team e dagli obiettivi a lungo termine.

Se devi integrare solo uno o due servizi esterni e le interazioni sono relativamente semplici, un’integrazione API diretta è spesso la soluzione più rapida. Se la tua web app deve solo verificare un token di pagamento Stripe al checkout, chiamare direttamente l’API di Stripe è semplice ed efficace. Introdurre MCP in questo scenario potrebbe essere eccessivo. Puoi connettere un agente AI a qualsiasi API REST documentata con una HTTP Action revisionata, oppure usare un’integrazione one-click come Google Sheets per registrare lead e richieste demo, senza eseguire un server MCP.

Nei casi in cui hai bisogno di un controllo molto stretto sulla richiesta/risposta (per ottimizzazione delle prestazioni, gestione speciale dei dati o protocolli proprietari), scrivere direttamente verso l’API può essere meglio. Le integrazioni tradizionali ti permettono di usare tutte le funzionalità avanzate di un’API e adattare le chiamate esattamente. Se un’API ha requisiti insoliti o se vuoi evitare qualsiasi livello di astrazione per massima chiarezza e controllo, l’approccio tradizionale è appropriato.

Per un esempio concreto di come gli strumenti MCP vengono esposti a un agente AI in produzione insieme ad azioni API personalizzate, vedi come gli agenti Quickchat AI combinano entrambi gli approcci. La discussione più approfondita su quando usare MCP, singole AI Actions o “Generate from Text” è in API per agenti AI: da MCP a endpoint personalizzati. Per provarlo tu stesso, segui la guida passo passo per connettere il tuo agente AI a un server MCP remoto, così potrà chiamare uno strumento live durante la conversazione.

Elenco dei server MCP disponibili

Se vuoi iniziare con MCP, consulta le directory dei server MCP qui sotto:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Puoi anche eseguirne uno senza scrivere codice: ogni agente Quickchat AI può essere trasformato in un server MCP con un URL ospitato che Claude, ChatGPT e Cursor chiamano come strumento. La connessione funziona anche nell’altra direzione: un agente Quickchat AI può chiamare il server MCP ospitato di un fornitore come propri strumenti, ed è così che l’assistente AI per la pianificazione basato sul server MCP di Calendly controlla la disponibilità reale e prenota riunioni da una chat, e così che un chatbot AI Notion risponde da un help center live e registra richieste di supporto in un database Notion.

Quickchat AI esegue anche un server MCP remoto per il tuo account. Collegalo a ChatGPT, Claude, Cursor o Codex e potrai gestire i tuoi agenti AI da lì: analytics, trascrizioni delle conversazioni, aggiornamenti della knowledge base e creazione di nuovi agenti, dietro un unico accesso OAuth. La procedura di configurazione per ciascun client è in Gestisci il tuo agente AI da ChatGPT, Claude e Codex con MCP.

FAQ

Funziona solo con Claude?

MCP è indipendente dal modello. Al protocollo non importa se il client è Claude, GPT-4, un derivato locale di LLaMA o un modello futuro, purché il client possa gestire l’interfaccia MCP. Questo significa che non sei vincolato a un singolo provider AI quando crei le integrazioni dei tuoi strumenti.

In che modo MCP è diverso dal fornire subito al modello tutte le informazioni di cui ha bisogno? Perché non riempire invece il prompt di dati?

MCP è fondamentalmente diverso dal riempire il prompt del modello di dati, perché consente al modello di recuperare informazioni dinamicamente quando necessario, invece di lavorare con un prompt statico e precaricato. Inserire testo nel prompt incontra limiti, perché i modelli AI hanno una finestra di contesto fissa, il che significa che troppi dati possono far perdere dettagli importanti, rallentare le risposte e aumentare i costi API (a causa dei modelli di prezzo per token usati dai fornitori di LLM). Inoltre fornisce conoscenza solo in un singolo momento, mentre MCP abilita l’accesso in tempo reale a dati esterni live e permette all’AI di compiere azioni, non solo leggere informazioni. Un’AI con un prompt pieno potrebbe conoscere i dettagli dei clienti, ma non potrà aggiornare record o elaborare transazioni.

Cosa succede se colleghiamo decine di strumenti all’AI? Non rischia di sovraccaricare il modello o di farglieli usare in modo errato?

Dipende dall’implementazione, ma è vero che gli LLM attuali hanno limiti nella capacità di distinguere e scegliere tra molte opzioni. Se presenti a un modello, per esempio, 50 strumenti possibili, c’è il rischio che ne scelga uno sbagliato. L’approccio MCP in sé non ti obbliga a caricare tutto in una volta. Dovresti collegare gli strumenti rilevanti in base al contesto. Una buona pratica è collegare solo gli strumenti necessari per l’attività/dominio in questione e sfruttare la collaborazione multiagente, una sorta di instradamento degli strumenti o un agente che decide prima quale sottoinsieme di strumenti considerare.

MCP vs Function Calling

Il function calling tradizionale (come si vede nell’API di OpenAI o in altri LLM) consente a uno sviluppatore di definire un insieme di funzioni, fornire le loro definizioni al modello e far sì che il modello le “chiami” per nome con argomenti. È stato un grande passo per l’integrazione AI, ma ha dei limiti. Una differenza importante riguarda quando e come vengono definiti gli strumenti. Nel function calling classico, tutte le possibili funzioni devono essere dichiarate in anticipo (in fase di progettazione) nel prompt o tramite l’API. Il modello può chiamare solo quelle funzioni fisse. In MCP, gli strumenti sono individuabili a runtime, l’AI può interrogare ciò che è disponibile e persino ottenere nuovi strumenti a metà sessione.

MCP vs GPT Actions e Plugins

GPT Actions/Plugins si riferiscono all’ecosistema di OpenAI in cui potevi abilitare plugin (come un browser web o un lettore PDF) per ChatGPT, o i “GPTs” (agenti ChatGPT personalizzati) che possono usare strumenti. Erano interessanti, ma richiedevano sviluppo personalizzato per ogni plugin ed erano limitati alle piattaforme di OpenAI. Se volevi un plugin ChatGPT per un’attività, dovevi creare un’API e un manifest, e passare dall’approvazione di OpenAI o almeno abilitarlo manualmente. Ogni plugin era essenzialmente un silo, un plugin meteo, un plugin viaggi e così via, ciascuno con i propri endpoint e la propria logica. MCP migliora questo concetto unificandolo e aprendolo.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) è una tecnica in cui un LLM viene integrato con una knowledge base esterna. In genere, RAG coinvolge un database vettoriale o un indice di ricerca: la query dell’utente viene usata per recuperare documenti o dati rilevanti (tramite ricerca semantica o altri metodi), e quei documenti vengono forniti al modello come contesto aggiuntivo da “leggere” durante la formulazione di una risposta. RAG riguarda il fornire al modello conoscenza che non aveva originariamente, ed è particolarmente utile per QA fattuale o informazioni specifiche di dominio. Tuttavia, RAG è in sola lettura, il modello recupera passaggi di testo, ma non esegue azioni oltre al recupero.

MCP, al contrario, riguarda l’esecuzione di azioni o di operazioni arbitrarie, non solo il recupero di contesto informativo. Con MCP, un’AI può fare cose: scrivere in un database, inviare un’email, eseguire codice e così via. Non si limita a recuperare conoscenza, può attivare modifiche in sistemi esterni. Quindi, per molti aspetti, RAG e MCP hanno scopi diversi.