Sistemi AI più potenti con il Model Context Protocol (MCP)

Sistemi AI più potenti con il Model Context Protocol (MCP)

I modelli di intelligenza artificiale, in particolare i modelli linguistici come GPT di OpenAI o Claude di Anthropic, stanno raggiungendo livelli di eccellenza sempre maggiori. La loro capacità di comprendere le nostre richieste si affina costantemente, e le risposte che forniscono sono sempre più precise e utili, rendendoli strumenti estremamente potenti.

Nonostante questa straordinaria evoluzione, permane una limitazione fondamentale che questi sistemi non hanno ancora superato, nemmeno in minima parte: l'incapacità di eseguire azioni in autonomia o di essere autosufficienti. Ciò significa che un modello linguistico non può, di per sé, accedere a strumenti esterni, database, server, API o simili. Per affrontare questa lacuna, è stata sviluppata una soluzione aperta e standardizzata: il Model Context Protocol, o in breve, MCP. In questo articolo, approfondiremo esattamente cosa sia questo protocollo, quali capacità offra e per chi potrebbe risultare particolarmente interessante.

A delineare queste problematiche e soluzioni è Golo Roden, fondatore e CTO di the native web GmbH, la cui esperienza si concentra sulla progettazione e sviluppo di applicazioni web e cloud, nonché di API, con una particolare attenzione alle architetture distribuite basate su eventi e servizi. Il suo principio guida è che lo sviluppo software non è mai un fine a se stesso, ma deve sempre essere al servizio di una specifica logica di business sottostante.

Cosa sia veramente un modello di intelligenza artificiale

Per comprendere appieno le potenzialità del MCP, è essenziale acquisire una visione chiara del punto di partenza e, in particolare, della vera natura di un modello di intelligenza artificiale. Molte persone tendono a credere che, ad esempio, ChatGPT sia esso stesso un modello AI. Questa percezione, tuttavia, non è corretta. ChatGPT è piuttosto un'applicazione sviluppata attorno a un modello di intelligenza artificiale. Il modello effettivo su cui si basa l'intera infrastruttura è disponibile in diverse varianti, come GPT-4o, GPT-4.5, o3 o o4-mini. Questi modelli costituiscono il vero e proprio nucleo di ChatGPT.

In realtà, questi modelli non sono altro che una funzione matematica – sebbene di complessità estrema. L'elaborazione del linguaggio funziona esclusivamente perché il linguaggio viene codificato in numeri, questi numeri vengono elaborati in modo intelligente e il risultato può essere successivamente ritradotto in linguaggio. In sintesi, si tratta di una funzione matematica altamente complessa, che si rivela eccezionalmente adatta a calcolare previsioni basate sul linguaggio. Nonostante ciò, rimane una funzione, priva di una comprensione intrinseca dei contenuti.

Perché i modelli AI necessitano di supporto

Da questa premessa deriva chiaramente perché i modelli di intelligenza artificiale non possano accedere autonomamente a database, server o API. Le funzioni matematiche non sono in grado di svolgere tali azioni, indipendentemente dalla loro complessità. Allo stesso modo in cui una semplice funzione come:

• f(x) = x²

non potrebbe pilotare un'API, neppure i modelli di intelligenza artificiale come GPT-4o sono in grado di farlo. È sempre necessario un intermediario che consenta l'utilizzo di questa funzione. Nel caso di GPT-4o, questo ruolo è svolto dall'applicazione ChatGPT. Si potrebbe quindi affermare che il modello di intelligenza artificiale è il cervello, a cui manca però il resto del corpo per agire nel mondo reale.

Come ChatGPT accede ai servizi esterni: il "function calling"

Si potrebbe obiettare che questa descrizione non sia del tutto accurata, dato che ChatGPT è effettivamente in grado di accedere a servizi esterni e a internet. Questa osservazione è corretta, ma l'accesso non è operato dal modello stesso, bensì da una funzionalità dell'applicazione che lo precede. Nel contesto di OpenAI, questa caratteristica è denominata "Function Calling". Il suo funzionamento, in termini molto semplificati, consiste nell'estendere il prompt con l'indicazione:

• "Se hai bisogno di informazioni aggiuntive per rispondere, puoi farmelo sapere."

A quel punto, il modello potrebbe segnalare di necessitare di una ricerca su internet, e OpenAI si occupa di effettuare tale ricerca al di fuori del modello. I risultati vengono successivamente reimmessi nel modello come nuovo input. L'accesso effettivo, quindi, è eseguito dall'applicazione, non dal modello stesso.

La limitazione delle soluzioni proprietarie

Il punto critico di "Function Calling" è la sua natura puramente proprietaria. È utilizzabile esclusivamente all'interno dell'ambiente OpenAI e non può essere trasferito ad altre piattaforme o modelli. Ciò vincola intrinsecamente questa possibilità a un unico fornitore.

È qui che interviene il Model Context Protocol (MCP). Offre un metodo unificato per connettere strumenti e servizi esterni ai modelli di intelligenza artificiale. In pratica, è l'equivalente di "Function Calling", ma in una variante aperta e standardizzata che può essere implementata da qualsiasi fornitore. MCP è stato sviluppato da Anthropic, l'azienda dietro Claude. Gli standard aperti sono generalmente considerati un aspetto positivo, e in tal senso, MCP rappresenta uno sviluppo estremamente benvenuto.

I tre ruoli nel MCP

Approfondendo il MCP, si notano immediatamente tre ruoli centrali: il modello, il server MCP e l'host. Personalmente, trovo che i termini siano un po' infelici, poiché la distinzione tra host e server MCP, in particolare, può essere inizialmente fonte di confusione. Per questo motivo, desidero chiarire innanzitutto questi tre ruoli.

Il modello

Il modello è il ruolo più semplice: si tratta di un modello di intelligenza artificiale o linguistico come GPT-4o, GPT-4.5, o3, o4-mini, Claude, LLaMa o DeepSeek R1, ovvero una rete neurale in grado di calcolare previsioni. È il "cervello" computazionale.

Il server MCP

Contrapposto al modello c'è il server MCP. Questo è un servizio che mette a disposizione funzioni o dati – ad esempio, inviare e-mail, interrogare database, controllare una webcam o effettuare ricerche su internet. In breve: qualsiasi tipo di funzionalità o di fornitura di dati. Rappresenta l'accesso al "corpo" delle azioni nel mondo reale.

L'host (o client MCP)

La questione cruciale è come connettere il modello e il server MCP, dato che i modelli non possono accedere autonomamente a tali servizi. Qui entra in gioco l'host. L'host integra il modello e lo esegue. Contemporaneamente, funge da client nei confronti dei server MCP esterni. Nel linguaggio del MCP, l'host viene quindi anche definito client MCP, il che, come accennato, complica ulteriormente la scelta dei termini.

È importante sottolineare: l'host rimane invariato per quanto riguarda l'integrazione del modello. Chi finora aveva un'applicazione che ospitava un modello linguistico, ha già svolto questa parte del MCP. L'aspetto interessante e innovativo si manifesta nella comunicazione tra l'host e i server MCP esterni.

Manifest e registrazione del server

Affinché una tale comunicazione possa avvenire, un server MCP deve essere inizialmente reso noto all'host. Questo passaggio è effettuato dall'utente. Ad esempio, un editor di testo o un IDE che gestisce un modello linguistico potrebbe offrire una funzione per registrare un nuovo server MCP. In questo processo, viene specificato l'URL del server.

L'editor di testo o l'IDE scarica quindi dal server MCP il file manifest.json. Questo file descrive in modo standardizzato quali capacità e dati il server MCP offre, come invocarli, quali valori di ritorno ci sono, come sono strutturati i parametri e così via. Spesso contiene anche modelli di prompt che l'host può utilizzare internamente. In questo modo, l'host è a conoscenza delle possibilità offerte dal server.

Quando l'host ora invia una richiesta al modello, estende il prompt con informazioni sugli strumenti disponibili dai server MCP registrati. Il modello stesso non ha bisogno di essere preparato specificamente per questo. Riceve semplicemente informazioni contestuali aggiuntive. Con queste informazioni, il modello può, se lo ritiene necessario per rispondere alla richiesta dell'utente, chiedere all'host di eseguire una delle azioni specificate nel manifest, delegando così l'interazione con il mondo esterno all'applicazione ospitante.